Hard-coded sRGB parameters in default high bit depth babl, GEGL, and GIMP

Why you might like to use Elle Stone's patched babl/GEGL/GIMP

As explained in Sections B and C below, the default high bit depth babl/GEGL/GIMP 2.9/2.10 code base contains hard-coded sRGB parameters that affect the result of just about every editing operation provided by the GIMP UI. So if you try to edit images in wider gamut working spaces such as Rec.2020, ACEScg, AdobeRGB1998, or ProPhotoRGB, the hard-coded sRGB parameters will incorrect editing results.

Unlike default babl/GEGL/GIMP ("default GIMP" for short), my patched babl/GEGL/GIMP ("patched GIMP" for short) can be used to edit images in any well-behaved RGB working space.

Operations in default GIMP that use hard-coded sRGB Y and XYZ values

The table below lists most of the GIMP operations that use hard-coded color space Y and XYZ parameters instead of the equivalent parameters pulled from the image's actual ICC working space profile. In default GIMP these editing operations produce wrong results for images in any color space other than sRGB.

In my patched GIMP, operations that use Y and XYZ values get these values directly from the image's RGB working space. However, a limitation on my patched GIMP is that the image must be in a well-behaved RGB working space, and for radiometrically correct results the image must be in a linear gamma RGB working space. I recommend that you use these well-behaved RGB working spaces from my github repository. If you run Gentoo, my ICC profiles are also available through Gentoo portage. If you've installed Krita, you already have the profiles as part of the Krita installation.

Operations in default GIMP that linearize the sRGB Tone Reproduction Curve

Default GIMP assumes all images are encoded using the sRGB TRC and then "linearizes" the sRGB TRC for various editing operations

To produce radiometrically correct color mixing, most RGB editing operations should be done on linearized RGB channel values. GIMP 2.9/2.10 — or rather babl, on which GIMP depends — does "linearize" RGB data before performing many RGB editing operations. But the babl code that does so assumes that the image ICC profile has the sRGB Tone Reproduction Curve (TRC), and so doesn't work properly with images in other RGB working spaces. Code has been added to GIMP that mitigates this problem. But the larger problem is that the "babl flip" take away the user's ability to control their own RGB channel data.

sRGB has a very odd "hybrid" TRC that is linear in the shadows and elsewhere equal to gamma=2.4, with the net resulting curve being "almost gamma=2.2" and also "almost perceptually uniform". No other standard RGB working space profile uses the sRGB TRC:

• AdobeRGB1998, BetaRGB, WideGamutRGB, and many other RGB working spaces use the gamma=2.2 TRC.
• ProPhotoRGB and AppleRGB use the gamma=1.8 TRC.
• Custom RGB working spaces often use the gamma=1.0 ("linear gamma") TRC.

For regular sRGB images, the babl "linearizing" code works as designed. It takes RGB channel data that's encoded using the almost perceptually uniform sRGB TRC and turns it into linear gamma RGB channel data.

For images in all other standard RGB working space, the babl "linearizing" code produces wrong results for the simple reason that the babl code is "linearizing" the wrong TRC.

Update: default GIMP now has code that checks to see if imported images are in linear gamma color spaces. If this is the case, GIMP constructs a new ICC profile with the original ICC profile's colorants and and the linear gamma TRC, assigns this new profile to the image, and also sets the image's precision to "linear" precision. And as soon as the user switches to linear precision ("Image/Precision/Linear Light"), the same thing happens. So the "window of opportunity" for wrong editing results because of the babl flips has been narrowed considerably and likely will be closed altogether by the time default GIMP 2.10 is released.

Please note that in most image editors "precision" refers to the bit depth of the image and whether it's floating point or integer, and says nothing at all about whether the image's ICC profile or channel encoding is linear gamma or perceptually uniform. GIMP's use of the phrases "Linear light precision" and "Perceptual gamma precision" is unique to GIMP, unless there's another babl-dependent image editor out there that provides similar terminology through the UI.

The default babl/GEGL/GIMP code that specifies whether to operate on linearized or perceptually uniform RGB takes away the user's control over her RGB channel data

High bit depth GIMP depends heavily on babl and GEGL. GEGL (and sometimes GIMP) tells babl whether any given editing operation should be done "linearized" RGB or perceptually uniform RGB, and babl then re-encodes the RGB values, flipping between the sRGB TRC and the linear gamma TRC, which works as designed and is actually not a bad feature for users who don't understand the requirements of radiometrically correct color mixing. However:

1. Sometimes developers do make mistakes, and so sometimes GEGL fails to ask for linearized RGB data, even when technically (that is, for radiometrically correct results) the operation should be performed on linearized RGB. For example, Curves and Levels are very important editing operations that as of June 2016 still operate on perceptually uniform RGB, when these operations really should be done on linear RGB. And sometimes GEGL asks for linearized RGB data when for most purposes the operation really should be performed on more or less perceptually uniform RGB data.
2. For some editing operations (for example making a Levels gamma slider adjustment) there really is no "right" way to encode the RGB data, in which cases the decision is purely an artistic decision, not a technical decision.
3. Sometimes the artist really does want to do exactly the opposite of what's technically correct, for example for artistic reasons.

My patched GIMP disables the babl flip code. This means that you, the user, must decide whether you want to edit linear gamma RGB or perceptually uniform RGB. You make this decision by converting your image to an appropriate ICC profile RGB working space. Personally I do most of my editing in a linear gamma color space. But occasionally I'll pull out a layer from an XCF layer stack, convert it to a perceptually uniform color space for specific editing tasks (for example posterizing an image, adding uniform RGB noise, and for most of GIMP's "Find edges" algorithms), and drag the result back to the original linear gamma layer stack.

Summary

As an sRGB-only image editor, high bit depth GIMP 2.10 will very nicely meet the needs of many current GIMP users, and especially users who don't understand (and don't want to understand) the basics of color management and radiometrically correct editing. But GIMP 2.10 will not meet the needs of potential new GIMP users with workflows that require editing in color spaces other than sRGB. And GIMP 2.10 is entirely unsuitable for anyone with an advanced workflow that makes conscious use of the differences between editing in linear and perceptually uniform RGB working spaces.

Differences between default high bit depth GIMP 2.9 and Elle Stone's patched "GIMP-CCE" goes over some of the differences between default GIMP and my patched GIMP from a user perspective. Tutorials and notes for using Elle Stone's patched "GIMP-CCE" provides additional information on using my patched GIMP.

Partha kindly provides precompiled binaries of my patched GIMP for Windows and Mac. How to build a version of high bit depth GIMP that's been patched to allow editing in any well-behaved RGB working space has instructions for building my patched GIMP on Linux.

I strongly believe that artists need access to free/libre image editors, and the more so now that Adobe's move to the cloud locks the results of a user's work into a proprietary file format that can't be accessed once the user's subscription expires. This is my main motivation for making my patched version of high bit depth GIMP available for people to use.

I'm pretty sure that eventually default GIMP will morph into an image editor that can be used in high end workflows. But this won't happen quickly. More developers contributing to GIMP developement will help a lot, and especially more developers who understand color management and the requirements of various high end workflows. So if this describes you, please consider joining the GIMP team.