[FFmpeg-devel] [PATCH] Add a gamma flag to exr loader to avoid banding

Ronald S. Bultje rsbultje at gmail.com
Tue Apr 29 16:32:50 CEST 2014


Hi,

On Tue, Apr 29, 2014 at 9:58 AM, Jimmy Christensen <jimmy at ghost.dk> wrote:

> On 29/04/14 15:18, Ronald S. Bultje wrote:
>
>> On Tue, Apr 29, 2014 at 2:49 AM, Jimmy Christensen <jimmy at ghost.dk>
>> wrote:
>>
>>  'm not sure that I like that it's default with gamma 2.2. Personally I
>>> would rather have it defaults to gamma 1.0 (no changes).
>>>
>>
>>
>> The gamma here is a little different from what you probably think it is,
>> it's the linear XYZ (that's the actual perceived rays of light shooting in
>> your eye as a scientific metric) vs. exponential RGB/YUV (which are just
>> matrix transformations of each other), such as sRGB or bt709 or whatever.
>>
>
> Huh? The gamma correction in the patch has nothing to do with the XYZ
> colorspace. As far as I can see it's a simple powf() applied.


Of course it's just a powf function, that's what exponential is, right?
This is about the _meaning_ of _why_ the powf is there.

There's such a thing as linear-rgb, and EXR may be coded as such. In that
case, xyz-rgb conversion is just a matrix transformation (just like
rgb/yuv), but conversion to exponential rgb/yuv (like srgb or bt709 or
smpte-blah) is an exponential function again - hence the powf.

The basic thing I want you to learn from this is that if you have a pixel
in the Y component of a YUV video frame that has 8 bits color depth (and
let's assume that it's full-jpeg-range 0-255, not mpeg range) and the pixel
has a value of 0x2, and the pixel next to it has a value of 0x1, it does
_NOT_ mean that if you put a light detector on the actual source of that
video frame, that the area covered by this pixel had double the amount of
luminescence coming off it compared to the area covered by the next pixel.

One-sentence summary: there is no linear correlation between pixel value in
your bitmap and luminescence.

That correlation is exponential, and the value of the exponent is the
gamma. Wikipedia or that webpage I linked earlier will explain why: we'd
waste pixels in value ranges where we can't really see the difference
between two consecutive binning values very well relative to other ranges
where we're actually much more perceptive to consecutive binning value
differences. To optimize the utility of our bitmap's bits, we use a gamma.

Ronald


More information about the ffmpeg-devel mailing list