Gamma correction

[AndrewGibb]

In view of @timholy's recent pull request, I thought I'd better raise the topic of Gamma, since we are concerned with being as correct as possible.
In brief, gamma correction is a nonlinear mapping applied to digital images at both capture and display, with the result that images are displayed in linear light. (In TV, this is largely an artefact of backwards compatible standards since the time of PAL/NTSC and not forcing everyone to buy new tellies.) The upshot for this package is that some* images do not record linear light (in a particular channel) rather, the sensor records linear light, then a process in the camera maps it to a non-linear space.
The bad news is that few (TV) camera manufacturers follow the standards precisely, opting instead for a particular "look" which is close to the standard, but not exact. Again, I can't say with certainty what happens with digital stills cameras. But unless the operating system is doing some very complicated pixel-wise gamma in the display, almost all digital image formats come with gamma-encoded pixels.

Having a brief look through the code, some support for this is already in place. Converting XYZ to RGB applies gamma (the function srgb_compand), but I can't see any of the conversions from RGB to other spaces undoing the gamma first.

Some possible solutions:

• Do nothing. This is how gamma is dealt with in most computer vision applications.
• Square RGB values to approximately convert to linear light before processing. This suggestion courtesy of Tim Borer, one of the authors of the paper mentioned here[1].
• Apply the sRGB/Rec709 gamma correction to RGB images, with an external interface to allow the user to specify their own function or look-up table for other colour spaces.

I imagine that the best solution will be very application specific. The errors introduced by doing nothing are usually very small, which is why most applications ignore them. But in feature film production, and some graphics applications they are treated more carefully. Currently, I handle gamma by creating custom image reading functions which first call imread, then apply whatever correction I choose before returning the image.

*I'm afraid I have no idea how widespread this is. TV cameras encodes gamma-corrected pixels. Digital film cameras do various manufacturer-specific things in an attempt to mimic the dynamic response of film to illumination, and the development process, which also involve non-linear encodings. The wikipedia[2] seems to suggest that digital stills cameras also encode gamma-corrected pixels. A remark @stevengj made about how MIME types work suggests that modern operating systems do not necessarily apply the same gamma correction to all images, but my anecdotal experience of looking at lots of images that I've de-gammaed doesn't support this. I'd be interested to learn more.

[1]http://www.ibc.org/page.cfm/action=library/libID=14/libEntryID=106/listID=2
[2] https://en.wikipedia.org/wiki/Gamma_correction

(edits for markdown formatting)

[timholy]

There's the invert_rgb_compand function; I can verify that repeatedly converting RGB->XYZ->RGB->XYZ preserves the value. But beyond that, I have no comment; colorimetry is not really my area of strength, here I'm acting as a slightly-educated code-janitor.

[rennis250]

I would at least like to see some interface for specifying my own gamma look up tables, as this is something that my colleagues and I always need fine-grained control over. I assume that high-end photography applications would also benefit from that kind of access. Aside from that though, I know next to nothing about color management practices. Do modern image and film formats carry metadata about this?

[KelSolaar]

Do modern image and film formats carry metadata about this?

Images that embed ICC profiles will usually describe the colour component conversion function (EOCF / EOTF) that maps from non-linear R'G'B' video component signal to a tristimulus value at the display.

If by film formats you talk about movie camera output, it is an entire different beast, they may have different file formats and very different conversion functions based on customised logarithmic function, the way to describe that is highly inconsistent.

We have a quite comprehensive amount of those here: https://github.com/colour-science/colour/tree/develop/colour/models/rgb/conversion_functions

And some more tied to RGB colourspaces definitions are available here: https://github.com/colour-science/colour/tree/develop/colour/models/rgb/dataset

Hope that helps :)

[AndrewGibb]

Do modern image and film formats carry metadata about this?

Some brief notes as I stick my head above the parapet of castle Thesis-writing:
In broadcast video, gamma correction functions are defined in standards, and the file format/wire format do not contain metadata specifying the parameters. There is a research project in BBC R&D at the moment which I plan to lobby to transmit data in linear light, and apply gamma at the display.
I've been working with ARRI ARRIRAW and RED EXR files for my thesis. ARRIRAW uses a logarithmic mapping from V_in to V_out, which I have not been able to find a formula for, but they do provide a free look-up table generator on the web. The EXR file format encodes gamma correction within the file format, alongside pixel values in linear light.