Modifying bab/GEGL/GIMP for editing in user-chosen RGB working spaces

Introduction: Patching GIMP to allow for editing in a user-chosen RGB working space

Why GIMP should provide for editing in RGB working spaces other than sRGB

As discussed on the GIMP developer mailing list (April 2016), it would be beneficial if babl/GEGL/GIMP were patched to provide for editing in other RGB working spaces:

• sRGB is based on Rec.709, which describes display technology from 1990. Today's printer and display technologies can provide much larger color gamuts than sRGB. But GIMP is currently stuck with a color gamut based on the display characteristics of consumer-grade CRTs from the 1990s.
• Critically important editing tasks require using RGB working spaces that are larger than sRGB.
• Allowing editing in non-sRGB working spaces would make GIMP a more viable free/libre alternative for artists/photographers/graphic designers who are seeking an alternative to Adobe's cloud-based software. Adobe's cloud-based software requires internet access and an on-going subscription fee, without which users loose access to the proprietary files that contain their hard work.

The source of the problem: hard-coded sRGB Y and XYZ values in babl, GEGL, and GIMP

GIMP can't be built without first building babl and GEGL. Many functions in babl, GEGL, and GIMP use hard-coded sRGB parameters. These parameters include:

1. The sRGB profile colorants (XYZ values) that are used to convert from sRGB to the XYZ reference color space.
2. The sRGB red, green, and blue Y values (taken from the sRGB XYZ values) that are using to calculate relative Luminance and Luma.
3. The sRGB Tone Reproduction Curve, which is used in the "babl flip code" that converts the image buffers back and forth between linear RGB and perceptually uniform RGB. The "babl flip code" is entirely separate from code that uses the sRGB Y and XYZ values.

This article only addresses patching babl, GEGL, and GIMP to replace the hard-coded sRGB Y and XYZ values with the corresponding values from the user's chosen RGB working space.

Full support for editing in user-chosen RGB working spaces would also require allowing the user to choose the TRC that represents perceptually uniform RGB (for example gamma=2.2, gamma=1.8, Rec.709, or the LAB companding curve). Currently babl only supports the sRGB TRC.

Code files and patches

Here is a spreadsheet that lists a total of 48+ babl, GEGL, and GIMP code files that use hard-coded Y and XYZ values. It's possible that I overlooked a few functions with hard-coded Y and XYZ parameters, but the list is at least very close to being complete. The spreadsheet shows which code files have been patched and which still need to be patched, and there are comments on what can be done regarding some of the individual operations.

Here are patches for enabling GIMP users to edit in color spaces other than sRGB. I also included several ICC profiles for testing the patches.

The original patches posted to this article were merely "proof of concept" because they were missing code that could transfer RGB colorant information from GIMP to babl. The current patches use babl_set_user_data and babl_get_user-data to transfer RGB colorant information from GIMP to babl, and so are much closer to being usable patches for actual image editing. Also the white space errors are gone.

To run the patched babl/GEGL/GIMP, you'll want to disable OpenCl, so an example "start GIMP without OpenCl" file is included with the patches. OpenCl code does currently incorporate hard-coded sRGB parameters, and this is another reason why it would be good to enable editing in user-chosen RGB working spaces sooner rather than later.

Patching GIMP to support editing in RGB working spaces other than sRGB

Patching GIMP to allow editing in RGB working spaces other than sRGB is a relatively straightforward "sit down and do it" coding operation, that can be broken down into five separate coding tasks:

1. My patches include code for GIMP that retrieves Y and XYZ from the user's chosen RGB working space. This code is called when the user switches from one image to another image with a different ICC RGB profile, but the current patch probably doesn't deal with all possible ways to change ICC profiles.
2. Write code for GIMP that converts the image from the user's chosen RGB working space to a variant of the chosen RGB working space that has the sRGB TRC, to enable the babl flip code to work properly.

   GIMP already has such code in the file libgimpcolor/gimpcolorprofile.c. This code currently is used when the user opens a linear gamma image, though it doesn't seem to be activated unless the user chooses linear precision. Similar code would need to be written and called for every image the user opens for editing (except of course for images that use the GIMP built-in sRGB profile). The new profile's TRC would need to be either the sRGB TRC or the linear gamma TRC, depending on the GIMP image precision (that is, Perceptual gamma vs Linear light).

   For testing the current patches, the user should start with an image that's been converted to an ICC profile that has the sRGB TRC, for example any of the profiles from Elle Stone's Well-Behaved ICC Profiles and Code that have file names that end in "-V4-srgbtrc.icc".

3. My patches include code that sends the user's chosen RGB working space Y or XYZ values from GIMP to babl, to be used as required by operations that are performed using babl conversions between RGB and Y or XYZ, using Option A below:

   Options regarding the information to be passed from GIMP to babl include:

   1. Code that conveys the 3x3 colorant matrix from GIMP to babl
   2. Code that conveys the actual ICC profile from GIMP to babl, in which case the relevant babl functions would need to use LCMS to retrieve the colorant matrix.
   3. Code that conveys a single integer that indicates "use one of the following built-in RGB working spaces":
      1. sRGB
      2. Rec.2020
      3. ACEScg
      4. AdobeRGB
      5. ProPhotoRGB
      6. (other RGB working spaces as appropriate)

         This latter option would require a UI change in GIMP to allow the user to choose a built-in RGB working space, plus code in GIMP that specifies the Y values for each RGB working space and code in babl that specifies the XYZ values for each RGB working space.

4. My patches include generalized babl/GEGL/GIMP functions that use the Y or XYZ values retrieved by GIMP.

   As indicated in the spreadsheet of hard-coded sRGB parameters in babl, GEGL, and GIMP, I've written patches for many of the 48 babl/GEGL/GIMP code files that currently use hard-coded sRGB Y and XYZ values. I've given a very low priority to files that use YCbCr, files for 8-bit GIMP plug-ins, and OpenCl files.

5. Write UI notifications for GIMP for cases when users open images with embedded ICC RGB profiles that aren't suited for use with GIMP.
   • RGB LUT profiles don't have colorants for use with operations that require using Y and XYZ.
   • Some RGB matrix profiles are not well-behaved and so don't make very good RGB working spaces.

   Writing UI code is pretty much beyond my coding abilities. So for testing the "open profile and get colorants" make-shift patch code for babl's extensions/CIE.c I used a selection of RGB working space profiles that are in fact well-behaved.

Conclusion: babl/GEGL/GIMP can be patched to allow for editing in a user-chosen RGB working space

Patching GIMP to allow editing in RGB working spaces other than sRGB is a relatively straightforward "sit down and do it" coding operation.

It would be preferable to patch babl/GEGL/GIMP to use parameters taken from the user's chosen RGB working space before too much more OpenCl code is written, as OpenCl code basically duplicates code written for use when OpenCl is not available. In any case, the longer patching GIMP to allow editing in RGB working space other than sRGB is postponed, the harder the task is likely to become.