Gamma in Color does not Match FCP Gamma

[Matt W.]

I'm editing something in Prores 444 1080p (nice codec except for gamma nightmares) and when I send my footage to Color from Final Cut it looks normal, then I grade it and send it back...and it ends up much darker than what I see in Color. So from Final Cut to Color is okay, but sending the footage back to Final Cut messes up the gamma somehow.

Anyone have any fixes?

 

[CJ Roy]

With Final Cut, the only real way to see what you're really getting is viewing with an external monitor via Kona, Blackmagic, etc.

FCP's canvas is pretty screwy in terms of gamma.

 

[Gunleik Groven]

But even if you watch through SDI, the levels will differ between FCP and Color with the same image...

You need a compensating LUT for color to adjust for this.

As this is partly codec-dependant (it seems), you're maybe best off doing a calibration with a chart that suits your choise of workflow...

Same way - if you calibrate your monitor for FCP, it won't be right for Color and vice versa...

 

[Stuart Smith]

But even if you watch through SDI, the levels will differ between FCP and Color with the same image...

You need a compensating LUT for color to adjust for this.

As this is partly codec-dependant (it seems), you're maybe best off doing a calibration with a chart that suits your choise of workflow...

Same way - if you calibrate your monitor for FCP, it won't be right for Color and vice versa...

Sorry, I've not found that to be the case, in 8 rooms running a Kona3 the SDI output matches between FCP and Color every time. If this is for Broadcast work and you have a calibrated broadcast monitor, there's no need for a LUT

 

[Nick Shaw]

I have found using a Decklink card the differences are there but very minimal when rendering to 10 bit uncompressed or ProRes(HQ). Rendering to ProRes4x4 is a different matter.

 

[Matt W.]

Thanks for the tips everyone. I have found prores 422 to be a lot better and I'll just use that from now on.

 

[Kaku Ito]

What I had mentioned before and not cleared is that REDLINE seems to render R3D to QuckTime only at 0 to 1023 video range. The FCP seems to wrap this up to 64 to 940, then if you send that to Color it goes back to show 0 to 1023. So not because of the gamma shifting, this is because of the video range. I asked Rubber Monkey and Craig said we can change the black and white point but unfortunately, they don't support the exactly the same number value as 64 and 940, so we have to calculate that to 0 to 100.

 

[Gunleik Groven]

Sorry, I've not found that to be the case, in 8 rooms running a Kona3 the SDI output matches between FCP and Color every time. If this is for Broadcast work and you have a calibrated broadcast monitor, there's no need for a LUT

OK...

 

[Hrvoje Simic]

Welcome to Apple.


It's not just the gamma.

 

[Gunleik Groven]

Could be a RGB vs YUV thingy.

I am usually in Color with RGB.
Checked with AJA 10-bit back in the day, as that was the relevant online format.

I, too, see that prores works better as to gammashifts.
There's other issues with prores, tho'

But I'll recheck.
Good when old myths/truths gets busted.

 

[Luca Immesi]

Please try this http://support.apple.com/kb/HT3712 (read gamma 2.2) and tell me what you think.

 

[Steve MacMillan]

Sorry, I've not found that to be the case, in 8 rooms running a Kona3 the SDI output matches between FCP and Color every time. If this is for Broadcast work and you have a calibrated broadcast monitor, there's no need for a LUT

Hi Stuart,

Which codec are you using (ProRes 4444?), and which version of Final Cut Studio and OSX are you using? And which version of the Kona software?

Thanks

 

[Tom.Wong]

what i had mentioned before and not cleared is that redline seems to render r3d to qucktime only at 0 to 1023 video range. The fcp seems to wrap this up to 64 to 940, then if you send that to color it goes back to show 0 to 1023. So not because of the gamma shifting, this is because of the video range. I asked rubber monkey and craig said we can change the black and white point but unfortunately, they don't support the exactly the same number value as 64 and 940, so we have to calculate that to 0 to 100.

why?!?! Why was i programmed to feel pain?!

 

[Kaku Ito]

Tom,

I don't think it's your fault, lol. Hope RED provides in SDK about white and black point output easier.

 

[Kaku Ito]

By the way, something thought after like 3CP might provide something because it's based on Color Finesse. I'll check when I get my upgrade.

 

[Hans von Sonntag]

What I had mentioned before and not cleared is that REDLINE seems to render R3D to QuckTime only at 0 to 1023 video range. The FCP seems to wrap this up to 64 to 940, then if you send that to Color it goes back to show 0 to 1023. So not because of the gamma shifting, this is because of the video range.

You nailed it. The full gamut, video gamut problematic is often mixed up with the infamous Apple QT gamma shift. As above said a Kona/BM card solves this issue for all folks that export to video. All others who use full gamut files for export and a video gamut for monitoring/reference need either a LUT or get hovering blacks. Or, if wide gamut was used for reference, get in their video deliverables crushed blacks and whites.

Nonetheless there ARE severe gamma shifts within Apple's QT that cannot be explained by the video vs wide gamut issue, which is obviously not an Apple related problem.

Hans

 

[Kaku Ito]

This issue is in the REDLINE, so hope RED adds white and black point selections in the SDK, maybe?

 

[Stuart Smith]

Hi Stuart,

Which codec are you using (ProRes 4444?), and which version of Final Cut Studio and OSX are you using? And which version of the Kona software?

Thanks

Hey Steve, OSX 10.5.8 (having some issues with 2 systems that had to be upgraded to Snow Leopard), FCP 7.0.2, Kona 3 ver 7.1 (heard of people having issues with 7.5) and ProRes HQ

I'm not saying Matt and Gunleik aren't having problems, it's just we have 10 rooms set up this way with calibrated broadcast monitors and have pretty strict QC standards there are no gamma shifts. And feeding Color and FCP through the same Kona card eliminates the need for any LUT

 

[Jim Collins]

Math Error in Color

Math Error in Color

There is also a pretty fundamental math error in the way the Color applies Lift, Gain, and Gamma. (I don't know if Graeme or someone else is going to stomp all over me. I can't believe I am the first person to notice this. So maybe I am all wrong.)

The correct formula for Lift, Gain and Gamma is:

Result = ((Value + Lift) * Gain) ^ Gamma

Applying Lift in Color should cause the histogram to shift to the left and right without changing shape which is what it does.

Applying Gain in Color should not move the left end of the histogram, but should cause the histogram to spread out towards and past the right end of the histogram. This is not what happens. The histogram grows from some point off the left side of the histogram. This indicates that Gain and Lift are being applied in the wrong order.

Similarly, applying Gamma in Color should not affect the right or left sides of the histogram but should only move the middle of the histogram. Again, however, this is not what happens. Both the left and right edges and the gain seem to be affected.

As near as I can tell the actual formula in the program is something like:

Result = Value ^ Gamma * Gain + Lift.

Unfortunately, while this should be a pretty simple bug to fix, it is also going to be very difficult to change since it is going to completely invalidate every color correction ever done.

 

[Dan Hudgins]

version code

version code

Unfortunately, while this should be a pretty simple bug to fix, it is also going to be very difficult to change since it is going to completely invalidate every color correction ever done.

If they include a version code in the CC, that can be used to pic the old math for old CC and if the new version code is in the CC then the new math can be used, so you keep compatibility, its a normal legacy issue.