[Gimp-developer] GIMP should fork babl and GEGL

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

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
Color management and free/libre photography

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