[Gimp-developer] High bit depth GIMP is excellent, awesome, amazing, if it's patched . . .

[Elle Stone <ellestone ninedegreesbelow com>]

High bit depth GIMP is an amazingly excellent and awesome image editor. 
I posted a tutorial on how to use some of the incredibly useful new 
features that will be unfamiliar to people using other image editors:

Autumn colors: An Introduction to High Bit Depth GIMP's New Editing 
Capabilities 
(http://ninedegreesbelow.com/photography/high-bit-depth-gimp-tutorial-edit-tonality-color-separately.html)

The tutorial shows how to use the new LCH blend modes to edit separately 
for tonality and color, and also shows some of the ways to use unclamped 
editing at 32-bit floating point precision.

High bit depth GIMP is *exactly* what I was looking for back in 2007, 
when I realized the various limitations PhotoShop was putting on my 
efforts to do radiometrically correct editing in linear gamma color spaces.

I don't mean the version of high bit depth GIMP that you get from git 
master. Unfortunately, default high bit depth GIMP 2.9 is still pretty 
much useless for anyone trying to do radiometrically correct image 
editing. For reasons why, see:

     * User's Guide to High Bit Depth GIMP 2.9 Color Management 
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html
     * Interoperability problems between GIMP and other high bit depth 
image editors, 
https://mail.gnome.org/archives/gimp-developer-list/2015-November/msg00003.html

I use a patched version of GIMP 2.9 for actual image editing: Patching 
GIMP for artists and photographers 
(http://ninedegreesbelow.com/photography/patch-gimp-in-prefix-for-artists.html)

My patched version of GIMP disables the babl flips, so to edit using 
linearized sRGB, the user must convert the image to a true linear gamma 
sRGB color space. This way the user KNOWS that her RGB data is encoded 
linearly, instead of being at the mercy of whichever developer 
programmed whatever operation to request RGBA or R'G'B'A.

My patched version of GIMP has the following additional features:

     * Simplifies the "Image/Precision" menu to five precisions: 8i, 
16i, 32i, 16f, and 32f.

     * Provides for LCH color picker information.

     * Replaces the default GIMP "Colors/Hue-Saturation" tool with an 
LCH-based "Hue-Chroma" tool.

     * Provides for decompose/compose to/from LCH.

     * Fixes a small error in GIMP's decompose to LAB 
(http://ninedegreesbelow.com/photography/lab-lightness-to-black-and-white-gimp29-photoshop.html; 
https://bugzilla.gnome.org/show_bug.cgi?id=755270; 
https://bugzilla.gnome.org/show_bug.cgi?id=755376).

     * Adds an "RGB Luminance" blend mode 
(https://bugzilla.gnome.org/show_bug.cgi?id=753163).

     * Makes "Colors/Desaturate" default to Luminance.

     * Can be patched to work in the Rec.2020 color space instead of sRGB.


If high bit depth GIMP 2.10 were released right now, exactly as it is - 
except with the babl flips disabled - it would be 100% useable for 
radiometrically correct, linear gamma image editing in the sRGB color space:

     * Users would need to convert 8-bit sRGB images to a higher bit 
depth precision and then to a true linear gamma sRGB color space 
profile. Also users could start with already high bit depth sRGB output 
from their raw processor, or could begin their digital painting at 
32-bit floating point precision.

     * Users who want to edit sRGB images at 8-bit precision would 
still need to edit images in the "almost perceptually uniform" regular 
sRGB color space, and they'd get results pretty much like what they get 
now using GIMP 2.8. Decompose to LAB would still produce wrong results, 
just as it does for GIMP 2.8 
(http://ninedegreesbelow.com/photography/lab-lightness-to-black-and-white-gimp28.html), 
and the LCH blend modes would produce similarly wrong results.


The babl flips would be incredibly useful if:

     1. Users had the ability to disable the babl flips.

     2. By default editing operations used RGBA. There are exceptions, 
that is, operations where a preprogrammed R'G'B'A alternative operation 
make good sense. For example:

          * A good case can be made for having the option to add RGB 
noise to linear AND to perceptually uniform RGB, at the user's choice.

          * The color picker works much better on perceptually uniform RGB.

          * Sometimes you don't want a radiometrically correct gradient 
or color inversion. Sometimes you really want the result of gradients or 
inversions done on perceptually uniform RGB.

     3. The babl flips could be used somewhat like a Blender node, to 
flip the RGB values to perceptually uniform RGB, at the user's request, 
instead of (as currently done) behind their back and without their 
knowing what's going on. It would allow a great deal more versatility 
for producing desired results if the babl flips provided a user choice 
regarding flipping to other TRCs, such as the gamma=2.2 TRC and the Lab 
Lightness TRC.

     4. There is something extremely disconcerting about having to 
convert a linear gamma sRGB image to regular sRGB in order to operate on 
linear gamma sRGB data:

          * It would be far less conceptually odd if, upon import (and 
only if possible given the image's embedded ICC profile), the image RGB 
values were *linearized* rather than given the sRGB TRC, as is currently 
required to get the babl flips to work as designed 
(https://bugzilla.gnome.org/show_bug.cgi?id=757783).

          * The code that requests and supplies RGBA and R'G'B'A would 
need to be modified to accomodate this change.


It would be nice if GIMP 2.10 could be used to edit using color space 
primaries other than the sRGB primaries, for example the much 
wider-gamut Rec.2020 or ACEScg color space primaries. For this to happen:

     * Code would need to be written that conveys the user-chosen 
primaries to the babl/GEGL/GIMP functions that use Y and XYZ to 
calculate Luminance and convert to XYZ, LAB, LCH, and grayscale, or else 
use concantenated matrices to accomplish the same thing.

     * Developer time being limited, maybe an easier alternative for 
GIMP 2.10 would be to program into GIMP at least one wide-gamut RGB 
color space, with Rec.2020 and ACEScg being excellent and obvious choices.

Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography