Re: [Gimp-developer] GIMP should fork babl and GEGL

(apologies for top-posting)

Hi Elle,

The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with multiple RGB color spaces. It will be
possible to create a babl format specifier which means
"whatever-the-artist-chose-for-this-image RGB".
All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
float" and similar) will be changed to use this new specifier.
Duplicate/side-by-side implementations of operations is not necessary nor
With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
ICC color profiles from inputs and set up the parameters for this color

I do not understand how this solution (once implemented) will not work for
your usecase. If you think it will not, please explain why.

I have no desired for a "sRGB only" workflow, and it does not help the
discussion to jump such a conclusion. Please do not assume that the
different needs are in conflict/adverserial to each other.


On 4 November 2014 19:27, Elle Stone <ellestone ninedegreesbelow com> wrote:

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 (
), "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:

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. 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 (

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).
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
//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

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" (
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

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, 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

With kindest regards,
Elle Stone
Color management and free/libre photography
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:

Jon Nordby -

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