Welcome to our community

Be a part of something great, join today!

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 :)

Autodesk Red Workflow

You beat me to the punch! :-)

The whitepaper is a description of a workflow from Final Cut Pro to our visual effects and finishing applications, using the latest releases.

The version posted on StudioDaily is actually slightly outdated; I got some last-minutes updates made to it on Thursday, you can download the latest version here:
http://images.autodesk.com/adsk/files/red_autodesk_whitepaper.pdf

Feel free to post comments on the workflow in this thread, and I'll be glad to respond to questions.

Cheers!
 
Marc-Andre Ferguson said:
You beat me to the punch! :-)

Feel free to post comments on the workflow in this thread, and I'll be glad to respond to questions.
Click to expand...

This is a very informative document that should be of benefit to everyone. Your findings regarding use of the PD985 LUT are very similar to what my own experiments have shown, but you also provide a plot to illustrate exactly why it's a good approach to take for film work. Good job.
 
A very informative document indeed, and consistent with my own experiences. As Mike says, seeing the plots is particularly useful in explaining the way the output LUTs work.

A couple of small items of feedback on the document:

One very minor point I would note is that you attribute the raised black level in the data to 'residual dark current'. My understanding is that the raised black level is an intentional choice by Red to set the A/Ds in the camera such that both the negative and positive going component of any noise is preserved.

On page 4 in the 'Film Deliverable' section you say "Crimson can display the individual RGB channels". Unless you have a much newer version of Crimson than is available to the rest of us (and I know something new is imminent) then Crimson does not show the actual imagery at all, and I assume it should read "REDCINE can display…"
 
mmost said:
This is a very informative document that should be of benefit to everyone. Your findings regarding use of the PD985 LUT are very similar to what my own experiments have shown, but you also provide a plot to illustrate exactly why it's a good approach to take for film work. Good job.
Click to expand...

Thanks!

On page 4 in the 'Film Deliverable' section you say "Crimson can display the individual RGB channels". Unless you have a much newer version of Crimson than is available to the rest of us (and I know something new is imminent) then Crimson does not show the actual imagery at all, and I assume it should read "REDCINE can display…"
Click to expand...

You're right, that's a typo. Drat, we'll get it in the next rev.
 
macgregor said:
It would be important to note that when exporting with log curves you must set the exposure to the equivalent of iso200 to avoid any clipping in the highlights.
Click to expand...

this is correct. recently did a super 35mm feature with couple of complete sences with red. Everything was CC using lustre. And we did re-export the red stuff with approx. 1.5 stop under exposed.
 
Marc-Andre Ferguson said:
You're right, that's a typo. Drat, we'll get it in the next rev.
Click to expand...

Marc-Andre,

We've recently tested this workflow between FCP and Flame/Inferno/Smoke 2008, and it worked for us, more or less.

We assumed that on page 4, within Crimson, Set File Specification to: EVENT#Z/F#&.E was meant to read EVENT#Z/#F#&.E .
Also on page 4, we totally ignored the statement Make sure that Use TOD/TC is selected as it just didn't work, and we used edgecode instead.

Marcus
Molinare Barcelona
 
Hello Marcus,
Sorry about the typo on export settings, we're getting it fixed.
Would you care to elaborate on the TimeCode issue? What exactly did not work?
Thanks!
 
Hello Marc-André
Background is that I'm an Inferno Op trying to establish workflows for Red material between FCP and Smoke/Flame/Inferno for our post work on TV commercials. It is our Final Cut dept. that maintain that in FCP the Time of Day code is not used. They say that the edge code, which on a small commercial shoot will be unlikely to exceed 03:00:00:00, is what is used and finds its way into the XML. TOD code can by definition go up to 23:59:59:24 (25 fps).
Anyway if we export from Crimson a series of DPX's with edge code, the subsequent conform or relink in Smoke/Flame/Inferno works. With TOD code, the material doesn't match the XML, is not "found", and the conform fails.

Please let me know if you think there is a way for FCP to use TOD code and why Autodesk recommends it.

Marcus
Molinare Barcelona
 
hey guys,

Simplest workflow would be take FCP edl and create dpx log using monkey extract is faster and easier. Would like to add one more point. Files out of RedCine is little softer than RedLine since sharpness added default to redalert and recline which is not the case with RedCine.
 
marcus.mcguinness said:
It is our Final Cut dept. that maintain that in FCP the Time of Day code is not used. They say that the edge code, which on a small commercial shoot will be unlikely to exceed 03:00:00:00, is what is used and finds its way into the XML.

....

Please let me know if you think there is a way for FCP to use TOD code and why Autodesk recommends it.
Click to expand...

This is not correct. When working with the proxies in FCP the timecode can be either ToD or edge code, depending on what was set on the camera as the 'primary' timecode. You can also change it in Red Alert by re-making the proxies. In fact the default in Red Alert is ToD, and "Use Edge Code" is a selectable option.

Also if you do not use the proxies, but convert in RedRushes, you can choose which timecode is used. And RedLine has "--useEC" as one of its arguments, and will use ToD otherwise.
 
Nice to see Autodesk using the same workflow I use already for their systems. Only 9 months late to the party.
 
marcus.mcguinness said:
Hello Marc-André
Background is that I'm an Inferno Op trying to establish workflows for Red material between FCP and Smoke/Flame/Inferno for our post work on TV commercials. It is our Final Cut dept. that maintain that in FCP the Time of Day code is not used. They say that the edge code, which on a small commercial shoot will be unlikely to exceed 03:00:00:00, is what is used and finds its way into the XML. TOD code can by definition go up to 23:59:59:24 (25 fps).
Anyway if we export from Crimson a series of DPX's with edge code, the subsequent conform or relink in Smoke/Flame/Inferno works. With TOD code, the material doesn't match the XML, is not "found", and the conform fails.

Please let me know if you think there is a way for FCP to use TOD code and why Autodesk recommends it.

Marcus
Molinare Barcelona
Click to expand...


Never had this issue. All but one of the 6 projects I have been involved with have been TOD code edited in FCP and had no issues.
 
RED 59.94 to Smoke

RED 59.94 to Smoke

Has anyone successfully edited with RED 59.94 proxies in FCP, rendered to DPX through Crimson and conformed in Smoke.

I have had plenty of success with 23.98, but 59.94 is not working.

If you have the answer please include a step by step procedure, so my head will stop hurting from trying to figure it out.


Thanks for your help.
 
possible typo in Autodesk White paper?

possible typo in Autodesk White paper?

Is their a typo under Video Deliverable in the Brightness parameter recommendation for Redcine? It says 25, but my tests show that .25 is what works quite well.

Also, under Film Deliverable the Exposure parameter is recommended to be -2 for Redcine, but my tests shows that -.2 is what works well.

Of course these recommendations are good starting places and each image should still be checked before rendering out for an online.
 
Hi Gregor, how are you doing?

Ah, the typos in our doc...
The original values were based on RedCine, and most of them got fixed for RedAlert, since I was suggesting that users use Crimson to import their R3D files.
So, you're right about the values you use.
 
So is FCP -> CRIMSON (DPX) -> Flame/Smoke still the best workflow ?
thanks
 
If you listen to the latest red centre podcast it sounds like there might be native support for R3D at NAB.
 
You must log in or register to reply here.
Back
Top