[FFmpeg-devel] [PATCH] Add a gamma flag to exr loader to avoid banding
ffmpeg at rgbaz.eu
Tue Apr 29 16:29:22 CEST 2014
On 29-04-14 15:58, Jimmy Christensen 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>
>>> '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
> 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.
>> It's not the gamma _over_ the non-linear YUV/RGB (which was already
>> non-linear in itself), which is the kind of operation that you get
>> when you
>> apply a gamma in e.g. gimp or photoshop on an image.
>> For typical gamma values for colorspaces, see e.g.
>> http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html - 2.2 is a
>> pretty typical default.
> My point is that you can never assume that the input OpenEXR's are
> gamma 1.0. Not to mention when you start to mix in ACES sometime in
> the near future.
> Assuming stuff which is not part/dictated of the standard is a bad
> idea IMHO.
> - Jimmy
As far as I know and have been using ACES and EXR,
OpenEXR is gamma 1.0 by standard:
If you store a photo of a light into an EXR, double the light's
brightness and store it again, the pixel values have doubled.
This is not the case with RGB or YUV images.
ACES is specifies EXR as the preferred fileformat:
and is also scene-linear.
Of course both have the option to use alternative gamma's
but it should be specifically written in the headers.
More information about the ffmpeg-devel