Autodesk RED Workflow Whitepaper

[Steve Sherrick]

Not sure if this was posted or not, but came across it today.

http://www.postmagazine.com/Media/MarketingManager/Autodesk Red whitepaper final.pdf

 

[Patrick Tresch]

They promote Crimson... and DPX workflow...

Don't they have any R3D integration?

Do they plan to use the SDK?

Strange conclusion to use PDlog instead of REDspace...

Patrick

 

[Steve Sherrick]

Patrick, as you know Assimilate is the only one with full R3D integration at the moment.

There has been mention that they will integrate it, but not sure what the timetable is and how deep that implementation will be.

 

[Marc-Andre Ferguson]

This is a proposed workflow using today's tools.
There are great third-party tools out there like Crimson and Monkey Extract to help you bring your R3D files into Smoke, Flame and Lustre. Our latest release (2009 Extension 1) contain tweaks to help you reconnect your DPX sequences to your FCP XML.

Unfortunately, I can't do like like Jim and tease you with screenshots of upcoming products, you'll just have to wait
Cheers!

 

[Kaku Ito]

Steve, good find. I worked with a colorist uses Autodesk and we went with REDlog but this document shows other logs would be better. Thank you for sharing.

 

[M Most]

Strange conclusion to use PDlog instead of REDspace...

It's not strange at all, assuming you're intending to output to film, and you understand how digital intermediates and color management work.

 

[Patrick Tresch]

It's not strange at all, assuming you're intending to output to film, and you understand how digital intermediates and color management work.

Yes, it's how cineon work and most DI suite are calibrated... but why use only 685 values when you have an 10bit latitude with 1024 levels? It's like trading off 35% of the signal. The same for Pdlog985 though there are only 39 values lost...

The extra headroom with PdLog685 was for argentic film values intedend and it's ability to record details in the burned area, as Digital media does not have any information after clipping point, what is the use of that extra handle?

Thanks

Patrick

 

[Meryem Ersoz]

Steve, good find. I worked with a colorist uses Autodesk and we went with REDlog but this document shows other logs would be better. Thank you for sharing.

How were the outcomes for you, Kaku? Were you disappointed? I'm still trying to understand how to make a right choice for a DI -- this whitepaper spells it out nicely, and the curves that they supply which illustrate various options are really quite helpful, RED should sticky these. Picture worth a thousand words, etc...

But it does seem that Redlog sets black and white references points which would be more favorable to the camera. And why is it that PD Log 985, the recommended setting in this paper, is only available in RedCine? And not RA or RR? Seems a bit of a limitation, since my workflow tends to interact among all three. Or am I missing something?

 

[M Most]

Yes, it's how cineon work and most DI suite are calibrated... but why use only 685 values when you have an 10bit latitude with 1024 levels? It's like trading off 35% of the signal. The same for Pdlog985 though there are only 39 values lost...

Because it's about proper mapping to film print density values, not a direct translation of digital to digital. With film, the white point is not the end of its recording capability, it is a rather arbitrary value chosen to represent what should be percieved in a film print as white. Since film is a logarithmic imaging medium, the amount of difference in percieved brightness between 685 (status M density of 1.37) and 1023 (status M density of 2.046) is not nearly as much as the difference between, say, 500 and 600. If done correctly, you're translating 12 bits linear to 10 bits log. You're not throwing away values, you're putting them where they belong in a print density mapping world. DI work is done this way so that the resulting values can be used directly by a film recorder that's calibrated to the Cineon standard, without additional LUTs other than those of the recorder itself. This allows accuracy and predictability.

Because, as you say, digital imagers don't have a "whiter than white" capability, and because of the specific characteristics of the Red's sensor, Red came up with different log mappings to better accommodate the needs of an industry that already has standards. And because the primary purpose of digital intermediate has been to prepare for a film recording, these standards are based on film science. It just so happens that the particular slope, toe, and knee of the PD985 LUT, when pulled down by about 1.5 to 2 stops, comes reasonably close to that standard, and allows for some reduction in low end noise, as well as more headroom on the upper end of the histogram. Their Redlog curve does not. Whether that's the reason they came up with the 985 LUT or not is something I don't know. But Graeme does. My guess is that it has more to do with SMPTE scaling for DPX output going to video display, but I could be wrong, and the similarity of the curve to a film curve might just be a coincidence. But if so, it's a happy coincidence.

 

[Deanan]

Because, as you say, digital imagers don't have a "whiter than white" capability, and because of the specific characteristics of the Red's sensor, Red came up with different log mappings to better accommodate the needs of an industry that already has standards. And because the primary purpose of digital intermediate has been to prepare for a film recording, these standards are based on film science. It just so happens that the particular slope, toe, and knee of the PD985 LUT, when pulled down by about 1.5 to 2 stops, comes reasonably close to that standard, and allows for some reduction in low end noise, as well as more headroom on the upper end of the histogram. Their Redlog curve does not. Whether that's the reason they came up with the 985 LUT or not is something I don't know. But Graeme does. My guess is that it has more to do with SMPTE scaling for DPX output going to video display, but I could be wrong, and the similarity of the curve to a film curve might just be a coincidence. But if so, it's a happy coincidence.

REDlog and the PDlogs serve two different purposes. REDlog provides a very efficient mapping from 12 to 10 for our sensor. REDlog seems to be a popular starting point at many facilities even though it does require a bit more work to massage it into a print density space. However, the distribution of the code values is more efficient which is worth it to some people.

PDlog 685 follows the standard implementation according to the spec but because the spec was designed for film, using the same transformation for a linear sensor doesn't work so well and you end up with a lot of wasted code values because of the curves angle. However you can use a standard log to lin tool to linearize. PDlog685 is what some people wanted because it was easiest to start grading with but is not something I'd personally use.

PDlog 985 is the same as 685 but with the white point at 985 so it uses more of the range and can be linearized with standard log2lin tools (with white point set to 985). Because the mapping is closer to PDlog, some people prefer to grade with this as a starting point.

REDline also lets you do more finessing with the PD curves but I don't think anyone uses it.

Print Density Settings:
--pdBlack <int> : Black point [default = 95, range = 0-511]
--pdWhite <int> : 90White point [default = 685, range = 512-1023]
--pdGamma <float> : Gamma [default = .6, range = 0.0 to 2.2]

 

[Meryem Ersoz]

very good, thank you for weighing in, Deanan. I'm struggling to understand the various Log spaces and their applications. This thread and the whitepaper are really helping to clarify. Also muddying the waters, but in an interesting way.

Will RED be adding PD Log 985 as a choice in RedAlert and RedRushes?

 

[Deanan]

Will RED be adding PD Log 985 as a choice in RedAlert and RedRushes?

It was in RA at first but got taken out because we had lots of feedback that no one was using it and it made the list confusing.

BTW, you can also use the usual lin2log tools to linearize REDlog very closely with:
black = 0, white = 1023, NGamma=1.022, Dgamma=1.7:

A shake node for that would be:
LogLin2 = LogLin(0, 0, 0, 0, 0, 0, rBlack, rBlack, 1023, rWhite,
rWhite, 1.022, rNGamma, rNGamma, 1.7, rDGamma, rDGamma, 0,
rSoftClip, rSoftClip);

 

[Cüneyt Kaya]

It was in RA at first but got taken out because we had lots of feedback that no one was using it and it made the list confusing.

BTW, you can also use the usual lin2log tools to linearize REDlog very closely with:
black = 0, white = 1023, NGamma=1.022, Dgamma=1.7:

A shake node for that would be:
LogLin2 = LogLin(0, 0, 0, 0, 0, 0, rBlack, rBlack, 1023, rWhite,
rWhite, 1.022, rNGamma, rNGamma, 1.7, rDGamma, rDGamma, 0,
rSoftClip, rSoftClip);

this information should be a sticky....so people have easy acces to this information

 

[Meryem Ersoz]

Is there any chance we get it added to RR and replaced in RA, please and thank you? I'm just a garden variety geek trying to swim with the uber geeks and need simple GUIs with little labeled buttons and sliders to push....

A sticky to this whitepaper or something like it, an abbreviated version with the illustrations only, might help new users make sense of the options. It isn't easy to dig a refined understanding of what the spaces represent from reduser.

 

[Marc-Andre Ferguson]

Thanks for chiming in Deanan,

Color is a interesting world to live in. Our workflow document is a blueprint, a starting point for working with the great images the camera produces. The color section is based on the results of serious camera tests and analysis.

There are exceptions to every rule, and saavy red users will usually tweak their images before pushing them out as DPXs. Remember that our applications are used for finishing, and color grading tools such as Lustre and the color warper in Flame and Smoke really shine when you feed them with images that have a lot of latitude to start with.

Having been in various situations with and around the RED ONE, I've witnessed many situations where DPs would hack the image to bits in Red Alert on the set, just to make sure they had the right latitude to play around in post. I've also seen editors blindly trust the QuickTime Proxies in FCP and turn them into ProRes to be timed in Color, losing a stop or two of available brightness, that they could have gained by tweaking the source image in RA and exporting new proxies. It's all a question of how you like the image you see on your monitor - provided it's properly calibrated and all.

In the end, there's no magic number, testing and experience are your keys to success.

 

[M Most]

this information should be a sticky....so people have easy acces to this information

Except that many, if not most, people will use it and wonder why the images are too dark.

Linearization, while often useful in a compositing environment, is not usually what you want in a digital intermediate situation. What most DI systems are designed around is log format, print density. That's what almost all print preview LUTs are designed to accept as their input, just as that's what essentially all film recorders expect as their input. As I mentioned previously, the DI industry is an industry that already has standards that are widely used, and work. What Red regards as technically "efficient" doesn't necessarily have any real value in an environment in which the primary deliverable is film. For that reason, they provide the print density LUTs, which yield a much better starting point under those conditions.