Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

REDCINE-X

I would be surprised that it do an actual conform, as that can get quite complex quickly. I am thinking that it will support the RED Rocket card which in some sense starts to become a Scratch Cine Light... Questions/wishes from my POV:

1. Support a pull list directly - having to index the entire rushes to take in a list that already defines which is R3D files to use is a waste of time. That's what pull lists do. Once pull list is loaded, then do a search for those files - re-index if needed at that point should the original UNC paths have changed. This would eliminate a lot of the working in batches due to memory overload.

2. Export an ALE file directly - need to eliminate some of the conversion steps in between. ALE should contain as much of the metadata possible - for example, both time of day and edgecode values.

3. Export all DNxHD flavors of QT.

4. Consistent naming and mapping of color parameters - support a common look file be it RLX or other to pass back and forth between RED supplied apps in a consistent way.

5. On PC, export an XML with RLX values into MetaFuze to encode directly to MXF wrapped DNxHD with all metadata. MetaFuze supports line command and XML scripting to be driven as a transcode engine.


Michael
 
I think a nice feature would be to be able to do some looks and "export" them as a single file (kind of like a ASC-CDL) that can be given to a "propper Grade suite (Scratch, Nucoda, Resolve, Luster, BaseLight etc) so they can import that as a "Look-reference" using the SDK setting. Kind of like a RSX but it would be nice if it could combine a bunch of looks into one file. If you go for the RSX-workflow I gues you have to put each RSX in its right folder for it to apply the grade to a specific shot.
A small txt file containing clipname and TC and the RAW-settings, that would be nice.
Maybe a new ASC-CDL needs to be stadardized, a ASC-RAW-CDL, containing the RAW-settings + normal CDL-settings.

A tool/function that automaticly looks at a watch-folder and ads any new clips into the timeline and also checks it for data-corruptions/errors. Like a file-verification.

"Tangent Wave" panel-support. (actually, don't add that, it might take some work away from me as a daVinci colorist :)

Support for video-out. I gues through RedRocket is in the pipeline, but using lets say a Kona3 or the MacBook Pro's second DVI-out as a videoout, and only get the image on that output. Leaving the 1st monitor for GUI.
Ofcoarce, have that as an option. So it still works to have a one-screen-setup.

A manual would be nice. A simple PDF would be enough saying what each button does.

A secondery layer. So you can key skintones and desaturate. A fixed 6 vector would be enough. + a "window"-layer to put on a vignette.
Although these tools wouldn't be used when making QT-Refs. Only when rendering out.


Seems like there is a bunch of new stuff coming after summer. RedAlert (just came), RedRocket and RedCine-x
Are we getting a new Linux SDK aswell?

/carl
 
MichaelP said:
I would be surprised that it do an actual conform, as that can get quite complex quickly. I am thinking that it will support the RED Rocket card which in some sense starts to become a Scratch Cine Light... Questions/wishes from my POV:

1. Support a pull list directly - having to index the entire rushes to take in a list that already defines which is R3D files to use is a waste of time. That's what pull lists do. Once pull list is loaded, then do a search for those files - re-index if needed at that point should the original UNC paths have changed. This would eliminate a lot of the working in batches due to memory overload.

2. Export an ALE file directly - need to eliminate some of the conversion steps in between. ALE should contain as much of the metadata possible - for example, both time of day and edgecode values.

3. Export all DNxHD flavors of QT.

4. Consistent naming and mapping of color parameters - support a common look file be it RLX or other to pass back and forth between RED supplied apps in a consistent way.

5. On PC, export an XML with RLX values into MetaFuze to encode directly to MXF wrapped DNxHD with all metadata. MetaFuze supports line command and XML scripting to be driven as a transcode engine.


Michael
Click to expand...

what he said.

with respect to #4 & #5 - the "common look file" - whatever it is - needs to be what we LOAD INTO THE CAMERA directly.
 
MichaelP said:
I would be surprised that it do an actual conform, as that can get quite complex quickly. I am thinking that it will support the RED Rocket card which in some sense starts to become a Scratch Cine Light... Questions/wishes from my POV:

1. Support a pull list directly - having to index the entire rushes to take in a list that already defines which is R3D files to use is a waste of time. That's what pull lists do. Once pull list is loaded, then do a search for those files - re-index if needed at that point should the original UNC paths have changed. This would eliminate a lot of the working in batches due to memory overload.

2. Export an ALE file directly - need to eliminate some of the conversion steps in between. ALE should contain as much of the metadata possible - for example, both time of day and edgecode values.

3. Export all DNxHD flavors of QT.

4. Consistent naming and mapping of color parameters - support a common look file be it RLX or other to pass back and forth between RED supplied apps in a consistent way.

5. On PC, export an XML with RLX values into MetaFuze to encode directly to MXF wrapped DNxHD with all metadata. MetaFuze supports line command and XML scripting to be driven as a transcode engine.


Michael
Click to expand...

Mark L. Pederson said:
what he said.

with respect to #4 & #5 - the "common look file" - whatever it is - needs to be what we LOAD INTO THE CAMERA directly.
Click to expand...

:iagree: ...this would be awesome!
 
Since I got my RED ONE, you guys never stopped surprising me!
Professional 35mm-like (almost, for the purists) for a really affordable price, great chances in the workflows (being able to edit in FCP directly from the proxies and finish in 2K in Color almost from scratch is simply something that stills amazes me!); absolutely great and never-before-seen (at least IMHO) customer support and the list goes on!
I think it's already been said, but if RC could import FCP XML files with no issues like having to conform through 3rd party softwares would be absolutely genius to me, at least then a first CC could be made for clients who don't want to spend money in a 4K conform... 'till they see one! :)
Oh! And don't get me wrong, just asking, you have really done a lot for your customers already!
The only thing I can say is: Thank you very much!!!!!!!
 
Jim,

Please publish a manual for Redcine-X. Documentation is key to the success of post production tools. Currently I have to train every new client on RedCine as no manual exists.
 
I'm in Stand by...


Cheers and Thanks
 
Matthew Duclos said:
haha. I love how quickly this turned into a request thread.
Even after Jim told everyone exactly what it is going to include.
Click to expand...

What are countint on the: "Specifications, prices and delivery dates are subject to change. Count on it"

;)

Michael
 
RedCine on Windows user here.

It would be nice if it would play nicely with other programmes. Both 3ds Max and Pshop sometimes get their knickers in a twist if Redcine is working. I feel it may be something to do with Direct3D drivers. Although other times it all works fine.

If there is any testing to be done I would be happy to join the beta for the PC

John
 
It would be nice if RedCine could write out RSX files to clip folders automatically. It provides a much nicer interface for grading a bunch of shots than having to manually open each on in Red Alert, but right now if you grade in RedCine you have to render in RedCine, which doesn't provide as much flexibility as being able to render through Red Rushes, RedLine, Clipfinder, etc.
 
I need to know how this will, or not, improve the Red post-workflow. The video is nice, but I don't see how it's an improvement, outside of cosmetic and hopefully some stability, for my clients. I need improved functionality for RedCine to find a home in the average RED workflow.

While having a very nice interface, essentially it's just a cool looking raw clip viewer. I'd just like to know what the differences are in terms of functionality. If it cannot conform, can it load more than 75 clips for apps like Crimson? Basically, is it 3rd party friendly? Will it have consistent looks across the board, with RA? These are the banes of the current Redcine, that make it almost useless for me and my clients.

Any info is appreciated. Thanks.
 
You must log in or register to reply here.
Back
Top