Is this the end of gamma issues?

[Nick Shaw]

My copy of FCS 3 isn't due to arrive until Monday, so I haven't tested this out yet, but I was extremely pleased to read the following in the online manual:

Because the Apple ProRes 4444 codec has been designed to work with Final Cut Pro and has a native gamma of 2.2, it automatically eliminates potential gamma shifts.

The use of the word 'automatically' worries me slightly. After all it's QuickTime's 'automatic' handling of gamma getting things wrong that causes the issues in the first place.

Can anybody who already has their copy verify if this is true? Try rendering an image from RED Alert as both ProRes 4444 and DPX, and open both in something like Shake which ignores Colorsync etc and see if they are identical.

 

[Simon Blackledge]

Picking up this afternoon... will post up when I've sent QT's to various apps.

Need to try Uncompressed >prores 444 also to find any potential shifting.

 

[Nick Shaw]

This is not a good sign!

Symptoms
Rendering PAL material to ProRes 4444 in Color introduces a gamma shift in the resulting video file.

Products Affected
Color 1.5, Final Cut Studio (2009)

Resolution
Avoid rendering PAL material to ProRes 4444 in Color as it can cause unexpected results.

Bugger!

 

[Kaku Ito]

I wonder how Apple put it that way in the manual since, the current display displays at 1.8.

 

[Kaku Ito]

Potential shifting happens especially from R3D or any RGB material rendered to YUV.

This even happens when Blackmagic 10bit 444 is converted to YUV422.

 

[Simon Blackledge]

Hmm is that ANY Pal? Or as in Pal captured YUV? :-/

 

[Nick Shaw]

This even happens when Blackmagic 10bit 444 is converted to YUV422.

That's why I use Shake to do that kind of thing, as it doesn't happen there.

 

[Kaku Ito]

Nick,

I tested briefly, 4K material at proxy displayed with MXO/FCP7(digital cinema desktop and the mastering mode), looks the same in MXO/Color 1.5, then render to QT 10-bit uncompressed looks the same back in FCP. This is with NTSC environment.

 

[Nick Shaw]

Just installed my copy of FCS3. Very pleased to see the "Gamma correction: automatic/none" option in the QuickTime ProRes dialogue box. Now if that option was available for other codecs too, and if Red applications let you access those QuickTime options…

Update: Oddly Apple have not put the gamma option into eg their Uncompressed 10 bit codec, which suffers from the exact same gamma issues that ProRes does.

 

[Ben Richardson]

I just tried 2k DPX > ProRes 4444 in Shake, and got black output. Anyone confirm?

 

[CraigDavidson]

Just installed my copy of FCS3. Very pleased to see the "Gamma correction: automatic/none" option in the QuickTime ProRes dialogue box. Now if that option was available for other codecs too,

CineForm has had that option for a year. FCP (6) made a number of assumptions about the gamma of the source material. The control panel for the codec allows you to render at the codec native 2.2 gamma, 1.8 gamma or the 2.6 that FCP sometimes expected. There is also an automatic mode, or "mixed" mode, that switches depending on the type of decode being requested from FCP

 

[Nick Shaw]

I just tried 2k DPX > ProRes 4444 in Shake, and got black output. Anyone confirm?

I can render ProRes4444 out of Shake no problem, and read it back in too with greater than 8 bit precision. Although there does appear to be some quantising going on. Also if you take that ProRes file and render it one generation in FCP (with 32bit float processing) you get a slight gamma shift. It's small (not the 2.2/1.8 shift we used to get) but you can't round-trip and be visually lossless.

 

[Ivan G]

I'm using the Aja codec and still have gamma issues with fcs3...