RED colour space workflow

[Hugh]

Hi all,

I downloaded some RED footage from here last week, and I've got a few questions.

I come from a film VFX background, where the majority of our footage is coming from film scanners as 10-bit DPX/Cineon files. Anything we get that's been rendered as CG is usually Linear floating-point EXRs. (0..1 Log range maps to 0..13.5 Linear)

Does anyone know what the definition of "linear" in both the DPX and Tiff files is? (The DPXs are certainly not Log...)

Would these images from the RED fit into a standard visual effects Linear pipeline? The files are 0..1 range, so maybe these images that look "okay" are heavily over-exposed (the greenscreen's green channel is maxing out, as is the highlight on the shoulder in the "strong light" sequence)

Treading the images as linear and adding our film lookup (truelight) gives very weird results. The 75fps shot looks like it's gone through a bleach bypass. Very desaturated (and the greenscreen goes a funny cyan)

So... what I'm wondering is whether anyone has looked into this any more. Is there a function to convert this linear into a film-pipeline linear? And should you, when shooting for a film pipeline, be looking to place the mid level exposure lower down the range?

 

[Hugh]

Oh, and having just had a fun read of a thread talking about Log/Lin/Video, I'd just like to point out that when I say Linear, I mean Linear Light. Not gamma-corrected linear, or video.

 

[Nick Shaw]

Hugh

Probably best if you download Redcine from http://www.red.com/support and look at the various options for exporting DPX etc. You can choose from various log options, rec709 (which is probably what was used for most stills you see posted on this forum) as well as the option to select a custom gamma. OpenEXR is also an output option, although one which I have not yet tested myself.

 

[Graeme Nattress]

YES, if we say linear, we mean a straight line. If you export from Redcine or Redalert as "linear", then that is what you get - a straight line mapping of the sensor data to the range of the output file. Best at 16bit this one, as 10bit dpx is not enough bit depth.

REDLOG is a log curve, like ViperLog or PanaLog - one that maps the whole sensor range into a curve that preserves max detail in 10bit for DPX export.

PDLOG gives two Cineon style log curves, with nominal white point at either 685 or 985. These may be more what you're used to when you think "log".

REC709 is the standard video HD gamma curve.

Graeme

 

[Hugh]

Thanks Nick - I'll take a look. If those shots have just been clipped to 0..1, then it's good to know that there is more data higher up the range.... I'll grab RedCine or RedAlert and find a .r3d file to have a look at...

And thanks Graeme too - It's good to know the difference between the two Log formats. Do you know what LogLin values would map REDLOG to linear? (blackpoint, whitepoint, dgamma, ngamma)

 

[Hugh]

I'm trying to track down some .r3d files to try this out with - I can't find any links in the footage tests forum - can anyone point me in the right direction?

 

[Nils Ruinet]

http://www.reduser.net/forum/showthread.php?t=5905

 

[Hugh]

Thanks - that's perfect

 

[Hugh]

I've had a look at those R3D files, and it's good to see what they give me myself.

The EXRs that I got out of RedCine are still 0..1 range.
The DPXs that I got out as REDLOG are 0..1
The DPXs that I got out as PDLOG are 0..0.669

In a film scan, that top 0.331 of the log curve corresponds to about 4 stops (closer to 3.75)

Is this basically the difference in dynamic range between Film and RED? (Which I thought was more like 1.7 stops less on RED)

Linear -> REDLOG appears to be a standard LinLog (in Shake) with white: 0, black: 1023, nGamma: 1.0235, dGamma: 1.7. This gives an accurate conversion +/- 0.001

I can't quite figure out the Linear->PDLOG conversion at the moment - I'm going to take another look later today - anyone got any clues on this one?

 

[Nick Shaw]

The EXRs that I got out of RedCine are still 0..1 range.
The DPXs that I got out as REDLOG are 0..1
The DPXs that I got out as PDLOG are 0..0.669

Since 0 and 1 represent the black and white points of the sensor, I can't see how you would expect to see any data outside that range. A digital sensor clips hard at both ends, so the only way there would be values outside the 0-1 range would be if they had been 'pushed' there by changing settings in Redcine. What would the point be of doing that intentionally?

What I haven't tested is what happens if you push the exposure in Redcine, so that some values do go above the white point, then export as EXR. Are the superwhite values preserved in the floating point data? Since Redcine uses (I believe) 16 bit half float for internal calculations, they should be.

 

[Hugh]

I think, having been reading through various other threads, that to get the result I want, I'd have to underexpose by 2-3 stops.

I think, as I mentioned before, that I'm just used to working with linearised film, which goes way above 1.

 

[Graeme Nattress]

If you want to retain all the range of the sensor, you normalize values to fit the whole range of available code words in the output format. So, if you're going out to DPX, you try to use all of 0-1023, and TIFF, 0-65535. To do otherwise would be to reduce image quality.

The PD Log modes "squash" the DR of the RED into a range that's commonly used for film scans. You either squash it down to 689 or 985 - remembering full range would be 1023. This has nothing to do with the DR of RED or film, but what, practicaly, works in terms of putting RED data in a form that doesn't scare people.

Graeme

 

[Cüneyt Kaya]

YES, if we say linear, we mean a straight line. If you export from Redcine or Redalert as "linear", then that is what you get - a straight line mapping of the sensor data to the range of the output file. Best at 16bit this one, as 10bit dpx is not enough bit depth.

REDLOG is a log curve, like ViperLog or PanaLog - one that maps the whole sensor range into a curve that preserves max detail in 10bit for DPX export.

PDLOG gives two Cineon style log curves, with nominal white point at either 685 or 985. These may be more what you're used to when you think "log".

REC709 is the standard video HD gamma curve.

Graeme

in redcine:
camera RGB

then i set gamma to
rec709:
choose this settings to output DPXs for 1080p finish.

REDlog/PDlog685/PDlog985----- like i understood this settings are desired if you output DPXs which are then used for Filmoutput.

My question now is, how is the workflow?
if you want to finish a dpx sequence with gamma REDlog/PDlog for filmoutput
AND finish with a dpx seuquence with gamma REC709 for a 1080p master.

..............................................................................................
How is the workflow so both sequences match the Color????
..............................................................................................

It could be that i mix two different things.
Then enlighten me.

And for the grumblers: no i dont want to finish at home, i just want to know,
how everything works and what are the best workflows.
I take advantage of graemes knowledge....and want to thank him in advance.


picture
1. rec709
2.redlog
3.pdlog 985

 

[Graeme Nattress]

All these "output" gammas come last, so you can change them at the end of the project and output as such. The color is identical for them all - it's the linearity that gets changed.

Graeme

 

[Hugh]

Graeme: Yup - that makes perfect sense. I'm just trying to figure out how it would fit into our current workflow.

I figured out how it does the PDLOG685:

Subtract 0.0074 from all channels
LinToLog with all standard settings, except Black at 0. (White: 685, nGamma: 0.6, dGamma: 1.7)

 

[Cüneyt Kaya]

after i do my offline with the quicktime wrappers at home, i export via redcine dpxs with different gammas, REDlog/Pdlog for final filmoutput and REC709 for a 1080p master.

In the posthouse, do i need two different gradings?

I dont think so, i think this is the step where i miss something.

(Is the answer something like: Hey K. when you grade you have the same colors, the different gammas make that you see a different look now, but after you have your filmoutput and watch this in a theatre, it will look the same like your footage with Gamma Rec709 on a HD DVD?)

 

[Hugh]

Is the answer something like: Hey K. when you grade you have the same colors, the different gammas make that you see a different look now, but after you have your filmoutput and watch this in a theatre, it will look the same like your footage with Gamma Rec709 on a HD DVD?

Not entirely (you knew that was coming, didn't you? )

If you do a filmout to actual film film, the characteristics of the film will make your images look quite a bit different from your rec709 look.

I wrote a bit of stuff about colour spaces (although more from a film VFX standpoint) on my blog - you can find the post here (I don't update that blog anywhere near as often as I should)

Anyway, if you have a look through that post, you'll see the image I used in Log, Linear, Linear-with-a-2.2-gamma and Log-passed-through-a-film-lookup.

If you wanted your DVD to look the same as your footage when printed to film and projected, you'd have to have a 3D LUT that would emulate your film print. You could then apply this to your images before creating the DVD. (They may, of course, require some kind of adjustment after, but the 3D LUT would at least have got them into the right space)

 

[Graeme Nattress]

Hugh, there's a black offset in the RED data. We preserve that so that you can see both sides of the noise floor around zero. The PDLog curves map RED black to Cineon absolute black, which is around 50 if I remember right, but you will see data below black, just as there is in the RED data.

Graeme

 

[Hugh]

That's great. Is this kind of thing documented anywhere?

It always bugs me when working with Linear OpenEXR versions of Log film scans where you end up with some noise data going <0.

 

[Graeme Nattress]

Hugh, if you need any details, just email! RED can provide the information you need to get the best out of the images.

Graeme