Whats up with the GAMMA SHIFTING???? color, fcp

[Uli Plank]

The Apple monitor is not really up to judging colors.

 

[SF Geek]

I got that. I'm not doing the most detailed color correction. I just want my gamma to be the same from final cut to color and back. Also the curves issue doesn't involve the monitor's accuracy.

 

[Uli Plank]

Well, so let's say that Apple just sucks regarding gamma – let's hope they eventually fix it in Snow Leopard…

 

[Robert Monaghan]

FYI..

The Gamma issue isn't really a problem within FCP. It is to do with MacOSX. (and to some extent QuickTime, too.) and RGB files.

Video/YCbCr based files are *always* Rec709 Gamma. RGB imagery can be, well, just about any gamma curve you wish.

MacOSX is currently using a Gamma 1.8 as its default gamma, which is based upon older (ancient, actually) QuickDraw api's from waaaaay back in Apple's past. The problem isn't specifically the 1.8 Gamma, either. The problem is to know when an image has a gamma of 1.8, 2.2, Rec709, etc.. When you look at an RGB image, you can guess which Gamma curved is being used, but its hard to know for sure.

On PCs/Windows/Linux, you can safely assume that either a Gamma 2.2 or a Rec709 curve is being used on a given RGB/YCbCr image. The two curves are very close, and when moving files around, the imagery looks fairly consistent. However, because the Mac uses Gamma 1.8 as its native RGB gamma, you start to see a lot of confusion. Which curve should be used? As most imagery doesn't have a flag to indicate what the gamma curve was, when the RGB image was created, you end up doing a guessing game. When you open an RGB image, you have to start guessing as to how to represent the RGB image, within your target gamma curve. Apple's gamma conversion is very messy at best. Mostly because assumptions have to be made most of the time.

The good news is this: On the various rumor sites, it is reported that Apple is supposedly going to switch to a gamma 2.2 native. If this is true, then in theory, all of these problems should simply go away. We'll see.

In the meantime, you can change the Mac's default Gamma. You should be able to change the OS settings to use a Gamma 2.2. This might improve the gamma shifting situation. I don't know how this is done, or if will affect QuickTime/FCP. But its worth a shot.

bob.
www.gluetools.com

 

[Antoine Fabi]

Thanks So much Bob !!!

For the first time, it's well explained with perspective!.

It is VERY complicated indeed.

It's not only a monitor gamma setting though, some apps will do the conversions right, other apps will do it wrong, no matter the monitor gamma setting.

Example:

Color shifts the gamma A LOT when exporting AJA 10 bit RGB file.
After Effect does not shift the gamma when exporting with the same codec.

I wish i could do coding...


Thanks for sharing, very helpfull.

Antoine

 

[Antoine Fabi]

Just a though...

NTSC...never the same color

now we have NTSG...never the same gamma...

Antoine

 

[Charles Angus]

This is what I do:

For Color, Shake, or AE (RGB applications) I set my monitor gamma to 2.2. These programs make no assumptions about monitor or footage gamma, and simply show it how it is. This is good.

For FCP (a YUV app) I set my monitor to 1.8. FCP always assumes your monitor is at 1.8 gamma, regardless of the truth, and will always apply a preview gamma correction on-the-fly in the canvas based on that fact.

FCP now has the ability for you to change the expected source gamma of RGB files, but you cannot change what it thinks your monitor is set to.

So, begin the monitor gamma dance...

 

[ericyoung]

...The good news is this: On the various rumor sites, it is reported that Apple is supposedly going to switch to a gamma 2.2 native. If this is true, then in theory, all of these problems should simply go away. We'll see...www.gluetools.com

If true, that would be great. Apple OS gamma has been stupidly stuck to for waaay too long.

 

[christiansprenger]

I talk to Bob every couple weeks or so.
He has been busy with Color for sure and seems very happy to play with RED Nativity in color.
Some new changes for Bob this new year it looks like.

Youll have to email him to see whats new.

Bobs bad ass.

Haha! Awesome.... glad he's doing well.

Yes, I shall!

 

[christiansprenger]

I got that. I'm not doing the most detailed color correction. I just want my gamma to be the same from final cut to color and back. Also the curves issue doesn't involve the monitor's accuracy.

I just experienced this as well. I will admit that my file structure is not exactly 'organized' so I suppose I will see if that has any influence on the problem. I am also experiencing your gamma shift - and I agree that it is not a gamma setting on my monitor. When I bring in the file, the blacks on the IRE scale are at about 10IRE.

The first render all -> send to FCP did not work and just gave me _M size files with no correction. So, I went back and tried to re-render in Color. I also went into the render directory of Color and played back one of the clips that is rendering using Quicktime. When I did so, the blacks looked HORRIBLY crushed (since I compensated and brought the blacks back down to around 1IRE) but once the file began to play... it looked okay. I suppose we'll see what happens once its done rendering.

 

[Kaku Ito]

I did some extensive experiments today and found out some things.

In FCP, I created using the "matte", control the crops and black level to create 100 % to 10% gradients (bars) so upon converting and go back and force between transcoding and apps, it would be obvious when some gamma shifting happens.

I first created the bars with the % in the black levels such as 100%, 90% and so on. But found out that it will not create or look like they fall to each levels of gains by looking at the FCP's waveform monitor, so I adjusted each level to match the waveform monitor (I guess it's because the matte is created with H.S.B. control?).

Then I set the timeline codec and watch out for the video processing choices to make sure I don't make mistakes. I rendered as Blackmagic 10-bit 4:4:4, AJA 10-bit 4:4:4, GlueTools DPX (with 709 gamma 2.2 setting) and ProRes 422 HQ to see the differences. Mostly the video processing was set to high precision YUV or 10-bit YUV (according to our findings on how some codec wraps 4:4:4 RGB to 4:4:4 YUV in FCP).

After exporting to each, I placed them on to each codecs' timeline. Blackmagic 4:4:4 and ProRes 422 HQ were consistent on FCP with each gain levels, but AJA 4:4:4 and GlueTools DPX gammas are shifted (remember I'm only talking about how they are in FCP at this point). AJA 4:4:4 went down by 10% and GlueTools gradually shifted down to 5% at last (so 10% became 5% gain level). Now I sent them to Color from each timeline with their own compressor (codec) settings to see what happens in Color.

Surprisingly, in Color, now GlueTools DPX and ProRes 422 HQ are showing the correct levels, but the Blackmagic 4:4:4 which was consistent in FCP now got lifted by 5%. For AJA 4:4:4, the 100% because 90% (same as FCP) but the 10% level went down to minus 5%.

Also without applying any grading in Color, simply render out as DPX (I posted in other thread but if you mix your timeline with RED clip it will let you output imported DPX file as DPX from Color, otherwise you won't be able to), the final DPX will shift down the lift about 5%, to be more exact, 100% will be 100% but from 90% to 10%, each level are shifted down by about 5%. But I won't worry about this too much because this is how we are submitting the files to DI, then they will prepare the LUT and apply the final grading in DI. I'll just make sure I don't crush the black leaving about 5% at the bottom.

From this result, I would trust GlueTools DPX (also CineForm stays consistent in gamma, too). Bob mentioned that GlueTools DPX renders in high quality YUV to preserve 4:4:4. So I would do offline edit in FCP with native or proxy (from R3D), hand over some clips that has to be composited with After Effects as CineForm 4:4:4, get that back as DPX or Cineform 4:4:4 (CG people are saying they're having some issues to render out as CineForm 4:4:4, so most likely I will get them as DPX), place them to native timeline (mix them and also apply wipes) then send it to Color and grade them together.

This is finally how I found it consistent workflow. It took me long time to figure out.

 

[Kaku Ito]

I also figured out that with Blackmagic 10-bit 4:4:4, sent to Color from FCP, then in Color, selecting the "override Header Settings" and select the Printing Density to be "Video 64 black - 940 white" on each clip will keep the DPX out from gamma shifting.

Would that limit the dynamic range comparing to Linear 0 black - 1023 white?

Also, the problem with this is that although I can keep the FCP and Color output consistent but readings in Color gets lifted. Arrrrgh!