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:
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.
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:
GEGL is developed for GIMP, and other projects.
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.
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:
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
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"
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
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,
Color management and free/libre photography
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list