Nuke! Which Gamma space is correct??

[Phil Moreton]

I have an editor that has exported from RedCine-X Pro to Quicktime 4k Prores 4444.
A VFX person is now working with the file in Nuke. They have finished the VFX but they need to know the gamma space.
Nuke defaults to Gamma 1.8?

Would this be correct for the VFX person to export at or should it be something else.

Original file was shot on Red Dragon with DRAGONcolour & REDgamma4.

Thanks in advance!

 

[Phil Moreton]

Any help on this would be great. Tried to search into this and my limited knowledge in the post production world is struggling to find the answers.
I told them to use the same colour and gamma space as the file they received but being told that Nuke defaults to Gamma 1.8.

 

[Kristin Stewart]

Choose Gamma 2.2.

Kristin

 

[Joseph Coleman]

Yeh, I had the same issue. Nuke is automatically interpreting Prores quicktimes with a gamma 1.8. Switch it to gamma 2.2 and output gamma 2.2 and you should be all good.

 

[Phil Moreton]

Hi Kristin & Joseph.

Thanks very much!!

 

[jake blackstone]

Original file was shot on Red Dragon with DRAGONcolour & REDgamma4.

For the umpteenth time- DRAGONcolour & REDgamma4 are just a metadata. It makes no difference what settings were used on a camera. Camera records RAW, which has no defined gamma or imbedded color gamut. Actually, technically speaking, the gamma is 1.

 

[Phil Moreton]

Jake, if you don't mind we were talking about Gamma in Nuke. Not gamma in the camera.
I just put it in my post so people who use nuke have all the information they might need to answer my question.

 

[Gavin Greenwalt]

EDIT:
Nope you're right 2.2 is correct for ProRes:

Apple ProRes codecs have a native gamma of 2.2

EDIT EDIT:

Ok, so I'm not sure if REDCine is setting the flag correctly but in Nuke if you output a ProRes file it sets the correct gamma in the metadata. So if you write a cineon ProRes it'll (default) to Cineon. If you write a 2.2 ProRes it'll (default) to 2.2. etc. That's why I was confused. I've had it default to 2.2 in the past and I've had it default to 1.8 in the past. Apparently it's "smart" enough if your writing application uses the flags.

I would be inclined then to use the 1.8 gamma if that's what the metadata says. But Whether REDCine is setting the flag is a question for RED. I would have them output you a TIFF and then compare it in Nuke. If the two match then you've used the right ProRes gamma. Otherwise I would try the opposite gamma.

 

[Nick Shaw]

Ideally in Nuke you want to work in scene referred linear. So unless the ProRes files were created with REDlogFilm gamma (in which case you should choose "Cineon" in the Nuke read node) none of Nuke's built in curves are "correct". All of them will give you a pseudo-linear result restricted to the 0.0-1.0 range, with compressed highlights and shadows.

If your ProRes is REDgamma4, you need to set your read node to "Linear" and then apply a REDgamma4 to unclamped float linear transform in another node. If you want to render out as ProRes, matching your source ProRes, you need to apply a linear to REDgamma4 transform at the end of your node tree, instead of a VLUT.

All that said, depending an what you are actually doing in Nuke, interpreting the ProRes using one of the built in curves may works adequately well for you.

Pardon the self promotion, but creating custom Nuke gizmos to do this kind of transform is a service I offer.

 

[Phil Moreton]

Ok, I got them to export a Tiff of Gamma 1.8 and 2.2
2.2 was better but your right the highlights and shadows are still compressed.

The ProRes files that were created were Redgamma4. I'll get the Nuke guy to try and set a read node to "Linear" and apply a Redgamma4 in another node.

Thanks for the help.

 

[Gavin Greenwalt]

If your ProRes is REDgamma4, you need to set your read node to "Linear" and then apply a REDgamma4 to unclamped float linear transform in another node. If you want to render out as ProRes, matching your source ProRes, you need to apply a linear to REDgamma4 transform at the end of your node tree, instead of a VLUT.

That's only partially accurate because you're forgetting the Quicktime Codec/Outputting application can be a total ass and apply its own color conversions as part of the codec/output engine... and then forget to undo them on decode. The full pipeline usually goes something like this:

1) REDCineX Debayer: 1.0 Linear -> REDGamma/RLF
2) ?? Quicktime ProRes Encoder: 2.2 -> 1.8 Conversion. ?? or 2.2 -> Rec709 Conversion (DNxHD) ?? or my personal favorite 2.2 -> Rec709 -> 1.8 (h264 sometimes).
3) ??? Unknown decode gamma ??? (This is why I recommend asking for a DPX still with all quicktimes so that I can noodle out whether or not my quicktime was wonked up).

So in nuke you get into a branching decision tree:

Option 1 - "Easy Option" aka how to work with it like you would in RCX.

1) IF Quicktime converted from 2.2 to 1.8 (Finalcut will do this) then you should use "1.8 gamma". (Technically this is wrong but it'll be close. The super technically correct way is to load as linear/raw apply a 1.8 to 2.2 gamma colorspace node and then apply a viewer gamma (sRGB) to linear colorspace operation. )
2) IF Quicktime converted from 2.2 to rec709 then you should use "rec709" (See above technically correct bonus points process).
3) IF Quicktime didn't do anything and the encoding machine's gamma matches your current machine's gamma then you should choose your viewer gamma (sRGB by default).

Honestly there isn't a case where you should use 2.2 except when you actually are using 2.2 as your viewer LUT, you should use sRGB if your viewer LUT is sRGB since then the read LUT and the viewer LUT will cancel each other out.

Option 2 - "The Correct Way"

If you want to linearize and remove REDGamma then you should:

1A) IF Quicktime converted from 2.2 to 1.8 you should load as linear/raw apply a "1.8 gamma to 2.2 gamma" colorspace operator. Then you should apply a REDGamma4 -> RLF LUT and use a log2lin node/or one of Nick or I's gizmos.
1B) IF Quicktime converted from 2.2 to rec709 you should load as linear/raw apply a "rec709 gamma to 2.2 gamma" colorspace operator. Then you should apply a REDGamma4 -> RLF LUT and use a log2lin node.
1C) IF Quicktime did nothing on its own then you should load as linear/raw. Then you should apply a REDGamma 4 -> RLF LUT and use a log2lin node.

2) As a final step in your comp if you want to return to REDGamma4 you should apply a Lin2Log operator and then use a RLF -> REDGamma4 LUT. On output you should then set your output gamma to "linear".

The "Safest" solution is to just make sure whatever you do on import you do the opposite of on output. Then you'll at least return the footage how you found it.