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

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.

Color management and free/libre photography

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]