our various gamma filters

FCP7 offers two gamma filters: "Gamma" and "Gamma Correction". Compressor3.5 offers one gamma filter: "Gamma Correction". The three filters work differently.

One trivial difference is that FCP7's "Gamma" filter interprets gamma inversely to the other two. So when comparing how the three filters effect gamma, you must enter, for example, 0.5 in the FCP7 "Gamma" filter and enter 2 in the other two filters. After doing this there are still three quite different gamma filterings done by these three filters.

Finding no serious documentation on these filters, I studied them experimentally. The experiments covered 8-bit Y' only. Findings*:

FCP7 "Gamma"
This is the clearest, simplest gamma filter. It presumes the input video has the standard range of Y' values 16-to-235. The range 16-to-235 is linearly shrunk to the real number interval 0-to-1, then raised to the power gamma, and then expanded back to the 16-to-235 range. So regardless of gamma, black value 16 remains 16 and white value 235 remains 235.

Compressor3.5 "Gamma Correction"
This is a pretty wild take on video gamma. It presumes the input video has the Y' range 0-to-255. That's a bit beyond the extended video range 1-to-254. The range 0-to-255 is linearly shrunk to the real number interval 0-to-1, then raised to the power gamma, and then expanded back to the 0-to-255 range. So regardless of gamma, the sub-black value 0 remains 0 and the super-white value 255 would remain 255 except it is output as 254.

FCP7 "Gamma Correction"
This one is so outlandish that it is probably a mistake. It presumes the input video has the Y' range 16-to-271. Where in the world did Apple's programmers find that 271 which can't even be written with 8 bits? Did they idiotically add 255 to 16? The range 16-to-271 is linearly shrunk to real number interval 0-to-1, then raised to power gamma,and then expanded back to the 16-to-271 range. A cap is placed at 254. So regardless of gamma, black value 16 remains 16, but there is no white value that's similarly fixed.

Algebraically:
FCP7 "Gamma"
Y'->(((Y'-16)/219)^(1/gamma))*219+16 [all Y'<16 become 16; no Y' becomes greater than 235 or 254, depending on the render settings]
Compressor3.5 "Gamma Correction"
Y'->((Y'/255)^gamma)*255 [no Y' becomes greater than 254]
FCP7 "Gamma Correction"
Y'->(((Y'-16)/255)^gamma)*255+16 [all Y'<16 become 16; no Y' becomes greater than 254]

The Compressor 3.5 "Gamma Correction" filter creates sub-blacks from standard video blacks whenever gamma > 1, and creates super-whites from standard video whites whenever gamma < 1. It can create sub-blacks as low as Y' value 0.

The FCP7 "Gamma Correction" filter creates super-whites from standard video whites whenever gamma < 1. When gamma >1 it significantly darkens every white, even a super-white 254, even super-duper 255. (Remember, it's trying to keep 271 fixed.) Thus the FCP7 "Gamma Correction" filter deviates from the classical idea of gamma. I think this filter was intended for input video with Y' range 16-to-254, but the programmers miswrote it.

Graphical comparisons of the three different gamma filters at 2x and 0.5x.

Within just two FCS3 applications we find three different ways to compute gamma. Among more applications we might find even more. Gamma is implemented sloppily in digital video. This is why when an application or device "shifts" gamma, the next application or device might not be able to "shift" it back.

Dennis Couzin
Berlin, Germany

*Note added 15 September 2012: the descriptions and the equations describe the filters' effects on Y' for grey scale images, which is how gamma is usually checked, rather than the filters' actual computation. See 15 September 2012 post.

Note added 22 October 2013: revised to reflect FCP7's "Gamma" filter's dependence on the render settings.

The gamma filter in Motion4 is exactly the same as FCP7 Gamma.

Unfortunately I don't know how to work Color1.5 in order to study its gamma filter. If someone wants to collaborate on this please PM me.

Dennis Couzin
Berlin, Germany

Hey DCouzin,

Good post. Yup. There are always some different intricacies behind how each softwares approach their math. Also, whether the process is based in Y'CbCr or RGB also makes a difference. Apple Color is an RGB processing app.

In theory, applying the same curve on each RGB curve should produce the same result as applying that curve on just the Y' curve, but that isn't the case in practice.

There are yet more differences- take a DPX sequence and transcode it to 8 bit and 10 bit Y'CbCr formats in After Effects and Compressor/FCP. When you don't get a gamma shift, certain colors may look noticeably different.

On a side note, I was reading some of the documentation on Premiere Pro, and they mentioned that it does certain processes in floating point linear light calculations, which is fine and dandy, except that there is no setting in PPro that lets you set the native color profile of the clip, which leads me to wonder about the accuracy of the linear light compensation that the process is supposed to be based on.



www.strypesinpost.com

Quote
strypes
In theory, applying the same curve on each RGB curve should produce the same result as applying that curve on just the Y' curve, but that isn't the case in practice.

I think you mean: In imagination, applying the same curve on each RGB curve should produce the same result as applying that curve on just the Y' curve, but that isn't the case in video color math."

It is one of the great horribilities of video color that while you can shuttle between the R'G'B' video and the Y'CbCr video all you want (except for piddly rounding errors**), you can't apply a curve in one and expect it to be the same curve in the other. BT.709 makes Y' = 0.2126 R' + 0.7152 G' + 0.0722 B'. If you (for example) apply 2× gamma by squaring each of R', G', B', and then compute Y', you don't get the square of the original Y'.* Also, after squaring each of the R', G', B', you get new values for Cb and Cr (from the other BT.709 equations). Shifting gamma in R'G'B' video or in Y'CbCr video causes color shifts, but they are different color shifts.

There's nothing inherently bad about shifting back and forth between our Y'CbCr based application and R'G'B' based applications. It's bad if the second application applies a gratuitous gamma shift which you then can't undo in, because it's not a gamma shift in, the first application.

You say Apple Color is an RGB processing app. The User Manual only discusses gamma in relation to Y', but it does make one ominous statement: "Gamma refers to two different concepts." Hmm...

Dennis Couzin
Berlin, Germany

*Note added 14 September: except when R'=B'=G', that is, on the grey scale.
**Note added 15 September: and also gamut losses

I think the reference in the Color manual is that in video gamma refers to the power law curve, and in film it refers to the slope of density curve (when plotted in log to get it to approximately a straight line). And as Color was used to grade film, gamma therefore had the two ambiguous meanings.

Using the video meaning of gamma, you're right that it has a different visual look whether applied to Y' or R'G'B'. This is often used by colourists to produce a visual effect by applying gamma to luma only and RGB, often in different amounts to produce the desire look in the colours.

Graeme

If you take the logs of both scales of the video power law curve you get the film straight line curve. Gamma as exponent in the first is gamma as slope in the second. It's the same concept in video and film.

Yet it is disorienting to come from film to video and hardly recognize ol' gamma. The reason is not the difference between logs and powers. It is in some constants figuring in the curves. Especially the high gamma film is expected to have higher Dmax than the low gamma film.

Whether in film or video, gamma applied to the separate R,G,B channels is inequivalent to gamma applied to a derived luminance channel. We see this in film when making a B&W print from a color source. Changing the gamma after making the B&W looks different from changing it before.

I completely agree that Apple Color's being an RGB processing app is no disadvantage for its purpose which is to change the video's colors. By all means get in the HSL (or whatever) sandbox and play.

But gamma is gamma is gamma. Any application that accepts a Y'CbCr video for gamma adjustment and returns a Y'CbCr video should have applied the function to Y' in a sensible way.* FCP7's "Gamma Correction" filter appears to be a botched attempt at gamma adjustment for video with Y' range 16-to-254. May be Color1.5 can do that filtering.''

Dennis Couzin
Berlin, Germany

*See correction posted 15 September.

I don't know exactly what the math is behind the different gamma curves, I just have a rough idea of what it looks like. The levels in FCP's 3 way color corrector looks very very different to Color, which looks closer to Colorista (eg. crank up mids in FCP7 on a dark shot, and the image looks very de-saturated, crank up mids in Colorista or Color and it skin tones still look reasonably natural.

Here's Colorista Free that you can download and have a look:
[www.redgiantsoftware.com]



www.strypesinpost.com

All our tone adjusters can and should be characterized. I recently studied the "mids" slider in the "Color Corrector" filter.
I applied mids shift 150 (lightening) and mids shift 50 (darkening) to a tone sample having Y' from 16-to-235. Evidently this mids slider preserves both Y' = 16 and Y' = 254 (or 255), while shifting the tones between. This is qualitatively like a gamma shift, which also preserves a black point and a white point, but it is quantitatively different -- it's its own curve. The closest approximating gamma curves are shown with broken lines. It exemplifies strypes' observation of large effect on highlights. This mids slider has much greater effect than the corresponding gammas in the upper tone range, and much smaller effect than the corresponding gammas in the lower tone range. The effect is exaggerated by Y'= 254 (or 255) being the assumed white point, because even Y' = 235 gets a trip from this mids slider. Mids shift 150 produces super-whites from all Y'>181, but after a broadcast safe filter is applied it's a mess of white.
What is this mids slider's curve? It looks like an arc of a circle. Did a graphics designer get his hand into Apple's toolkit here?

Dennis Couzin
Berlin, Germany

My first experiments were on grey scales. For grey scales a gamma shift appears as changes in Y'; Cb and Cr don't change; the grey scale remains a grey scale.

But this doesn't mean the gamma filter's algorithm should ignore Cb and Cr and just operate on Y'. Camera gamma operates on each of R,G,B. Monitor gamma operates on each of R,G,B. So it's sensible that midstream gamma shifters also operate on each of R,G,B. The algorithm must effectively: convert Y',Cb,Cr to R',G',B'; apply gamma to each of R',G',B'; convert back to Y',Cb,Cr. The result on Y' is generally different from applying the gamma directly to Y', and there are changes to the Cb and Cr, but this sensible.

FCP7's "Gamma" filter behaved correctly for the Y' 16-to-235 grey scale, so I examined its effect on non-greys. It appears to do exactly what's bolded in the paragraph above. (The conversions should allow non-integer R',G',B', and they should also allow values over 255 which eliminates some clipping of the Y'CbCr gamut. FCP7's algorithm doesn't do the latter.)

There's yet another gamma filter among the FCP7 Image Control filters. It's part of the "Levels" filter. It explicitly operates on R,G,B, which I now see is normal. Unfortunately this filter imitates the bum FCP7 "Gamma Correction" filter, trying to preserve Y'=271 white. Sigh!

Dennis Couzin
Berlin, Germany

The September 2012 experiments, performed with an 8-bit test clip, found the FCP7 "Gamma" filter to be a rare flower: an unflawed Apple video filter. I just retested the filter on a 10-bit uncompressed test clip. It output correct, unclipped 10-bit results over the 64-to-1019 range. Wow!

Dennis Couzin
Berlin, Germany