[Gimp-user] GIMP should fork babl and GEGL

[Elle Stone <ellestone ninedegreesbelow com>]

Below explains why GIMP should fork babl and GEGL for use just with GIMP:

Hacker News picked up an article from my website: The Sad State of High 
Bit Depth GIMP Color Management
(http://ninedegreesbelow.com/photography/sad-state-of-high-bit-depth-gimp-color-management.html)

In the Hacker News comments (https://news.ycombinator.com/item?id=8549560
), "unhammer" said:

//begin quote
From glancing over it, it seems to me like Elle Stone wants GIMP to 
make a rather radical shift to Do The Right Thing, while Øyvind Kolås 
(Pippin) values making small improvements one step at a time to avoid 
breaking current functionality.
//end quote

unhammer's otherwise excellent summary overlooks one very important 
point, which is that there is absolutely *no* current functionality in 
GIMP that would be broken by Doing the Right Thing, which is to give 
GIMP proper ICC profile color management.

The only caveat is that a very few GIMP UI functions really do need to 
be labelled as "only for device sRGB images" or in some cases "only for 
device NTSC images". This article lists all such functions: 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html

Moving back to the Hacker News comments, our very own Jon Nordby 
("jononor") reveals precisely where the "current functionality" that 
would be broken by Doing the Right Thing actually resides:

//begin quote
GEGL is developed for GIMP, and other projects. 
http://www.jonnor.com/2014/04/imgflo-0-1-an-image-processing... 
http://www.jonnor.com/2014/11/imgflo-0-2-the-grid-launched/ Disclosure: 
I'm a GEGL dev and the imgflo maintainer.

The 'other projects' part is one of the reasons why the proposed 
solution 'just strip all colorspace info, assume it is the same 
throughout entire processing pipeline' is not acceptable for GEGL, even 
if that might somewhat close to the typical usecase for GIMP.
//end quote

In other words, nothing in *GIMP* would be compromised or broken by 
Doing the Right Thing. However, Nordby's other projects *would* be 
affected. Of course his other software could be patched to assume sRGB 
as the image input profile, but perhaps that is something he doesn't 
want to do.

As an aside, by "just strip all colorspace info", Norby seems to mean 
replacing hard-coded sRGB parameters with equivalent parameters pulled 
from the user's chosen RGB working space, which is precisely the Right 
Thing to Do for GIMP.

The ICC profile color management problem with current GIMP 2.8/2.9 is 
that some babl/GEGL/GIMP functions are written using hard-coded sRGB Y 
and XYZ parameters. These functions necessarily give wrong results if 
you, the GIMP user, try to edit images in other RGB working spaces such 
as AdobeRGB1998, BetaRGB, or ProPhotoRGB 
(http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html).

The "Right Thing to Do" for GIMP is to use LCMS to retrieve the Y and 
XYZ values from the image's actual user-chosen ICC working space profile 
and then use the Right values instead of the Wrong values.

Moving back to the Hacker News comments, Jon Nordby said:

//begin quote
This article is primarly a strawman argument, the 'architecture' which 
is so adamantly argued against has already been abandoned (much thanks 
to arguments from OP). 
https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74 It has 
however not magically implemented itself yet.

This is somewhat recognized in the article section which starts "There 
is a ray of hope". The implication that the issues demonstrated will go 
away as a consequence of this has somehow been lost, possibly due to 
miscommunication.
//end quote

My article does not present a strawman argument. Based on his last post 
to the GIMP developer's mailing list, head babl/GEGL developer Øyvind 
Kolås is still clinging to his hopelessly broken unbounded sRGB model 
for image editing.

If Kolås had really given up on unbounded sRGB, he wouldn't still be 
saying things like "Using a fixed linear RGB format instead of userRGB 
is what for some operations will provide the consistent results for the 
same property values / slider positions" 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00096.html). 
For those of you who don't speak "bablese", "fixed linear RGB" means 
linear gamma unbounded *s*RGB.

Kolås's desire for "consistent slider results" betrays his failure to 
understand the nature of color-managed RGB image editing. Yes, many 
editing operations do produce different results in different RGB working 
spaces. This is precisely *why* we have different RGB working spaces. 
The ONLY person qualified to pick which RGB working space to use for any 
given technical or artistic purpose is YOU, the GIMP *USER*.

Kolås's plan seems to be to use unbounded sRGB whenever and wherever 
possible, with Kolås being the judge of "whenever and wherever possible".

Nordby's plan seems to be to "eventually" implement side-by-side 
babl/GEGL processing for sRGB and for the user's choice of RGB working 
spaces. This plan unnecessarily complicates the code and totally ignores 
the fact that sRGB is just another ICC profile RGB working space that 
needs *no* special treatment.

The only way I can see for GIMP to get out of this babl/GEGL "hard-coded 
sRGB mess" is for GIMP to fork a babl/GEGL branch meant specifically for 
GIMP. That way Nordby can have his "sRGB only" branch, Kolås can play 
with unbounded sRGB, and GIMP can have proper ICC profile color 
management without having to take a backseat to the needs of other 
babl/GEGL projects.

Another advantage to forking babl and GEGL for GIMP is that GIMP's fork 
of babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW 
(Fourier transforms, http://www.fftw.org/) and other new functionality 
to GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what 
GPL code can be used for new editing functions because the babl/GEGL 
code is LGPLed.

With kindest regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography