Log vs. Lin vs. REDspace?

[Ben Brainerd]

Apologies if the has been asked before. It's one of those things that's hard to search for without getting a lot of extraneous stuff.

I'm posting a couple of RED projects at the moment. I feel I've got a pretty good handle on working with the various video color/gamma spaces (REDSpace, Rec.709). What I don't necessarily understand are Log and Lin.

I know (at least I think I do) what Log *does*, at least as far as theory goes. I'm not so sure about RED's linear light setting, though.

What I don't understand is where these options fall into the post workflow. I know Log require a LUT before I can really work with it. That's about the extent of my knowledge.

I guess my questions are such:
1) What, if anything, would I be gaining by moving to a Log DPX workflow vs working with the R3Ds in Color as I'm currently doing? (Besides needing a boatload of storage space...)

2) What workflows lend themselves more towards working in Log? My current thinking is that if I'm working on a video project, I might as well stay in the video spaces. Am I horribly off base with that?

Anyways, if someone could help me out, it'd be much appreciated. Or at least point me somewhere I can get more info.

 

[Dan Hudgins]

LOG vs. video gamma

LOG vs. video gamma

You do not need a LUT to use REDLOG if you output to a TIFF file, the images are lighter in the mid-tones than sensor linear so it is more like a gamma adjusted image.

Once you get the REDLOG TIFF into your CC software you just adjust the S curve and you can output video gamma, maybe with some chroma matrix to increase the saturation.

Color correction for filmmaking is not reproducing test charts, you have to take into account the coloring of the subject and the lighting and to bring out the eyes of the actors with changes to the gamma and curves and such.

You can try doing CC on REDLOG in my programs for "freeish" now.

I recomend REDLOG since the mid tones are lighter and closer to where you would want them, linear would require large gamma changes so its best to start with something close to right and just make smallish changes before output as video gamma for transfer to the film recorder in 16bit TIFF. Having 16bits (48bpp) TIFF gives the film recorder more bits to scale with its curves and LUTs.

 

[John Jonathan]

guess my questions are such:
1) What, if anything, would I be gaining by moving to a Log DPX workflow vs working with the R3Ds in Color as I'm currently doing? (Besides needing a boatload of storage space...)

R3D's are super super super super slow to work with Natively in COLOR. A 10bit DPX from an R3D will move lightyears faster than working with R3D's.

This will change in years when COLOR gets optimized for the RED Rocket™, but don't hold your breath.

2) What workflows lend themselves more towards working in Log? My current thinking is that if I'm working on a video project, I might as well stay in the video spaces. Am I horribly off base with that?

LOG is a format invented by KODAK to retain the high contrast and detail of film scans in just a 10bit file. A 10bit LOG file has the same contrast as a 16bit LIN file. And a 10bit DPX is only 12megs per frame and a 16bit LIN is about 250megs PLUS per frame.

Start with Steve Shaw at Light Illusion.
http://www.lightillusion.com

 

[Ben Brainerd]

Light Illusion definitely looks like a good reference, thanks.

I hadn't realized DPXs were that much faster in Color. That might be enough for me to try it out right there.

So my workflow would look something like: FCP -> EDL/XML -> ClipFinder/Crimson Render -> Color? Something like that?

I guess it's gonna need more research. And more HD space.

 

[Steve Sherrick]

R3D's are super super super super slow to work with Natively in COLOR. A 10bit DPX from an R3D will move lightyears faster than working with R3D's.

This will change in years when COLOR gets optimized for the RED Rocket™™, but don't hold your breath.

Are you referring to playback, rendering, or something else? I haven't found the RED-Color workflow to be all that slow. Certainly not as fast as other higher end finishing systems but for the price point and what I use it for, works pretty well.

 

[Nick Shaw]

a 10bit DPX is only 12megs per frame and a 16bit LIN is about 250megs PLUS per frame.

This is not correct. At 4K 16x9 a 10 bit DPX is 27MB and a 16 bit TIFF is 36MB. 12MB is the size of a film 2k (2048x1556) DPX. Don't know where you got 250MB.

It's not quite as simple as saying "DPX is faster". If, for example, you want to work from the 4K de-Bayer and scale to your deliverable size, to go the DPX route you need a drive array capable of reading 4K DPX files at high speed, or that is a major speed bottleneck. Working from the R3Ds the drive requirements are much less, although a fast drive to write the renders to helps.

As always, test for your own requirements, and see what works for you.

 

[John Jonathan]

Are you referring to playback, rendering, or something else? I haven't found the RED-Color workflow to be all that slow. Certainly not as fast as other higher end finishing systems but for the price point and what I use it for, works pretty well.

When you grade in COLOR using Native .R3D files it is a lot slower then using a HD quicktime or DPX files. Having a Primary and 8 secondaries, it goes at a snails pace.