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

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/04/2014 02:31 PM, Jon Nordby wrote:
> (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 planned.

> 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
> space.
>
> 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.
>
> 1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74

What you just described IS side-by-side implementations of operations. 
In an ICC profile color-managed application, sRGB is just another RGB 
working space. You don't need to special-case sRGB.

Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.

In Pippin's originally planned "unbounded sRGB architecture", "bablRGB" 
meant "convert the image to unbounded sRGB before perfoming *any* 
editing operation". Now the plan is that bablRGB will mean "convert to 
unbounded sRGB for *some* operations".

But thankfully the "convert from UserRGB to unbounded sRGB" code has not 
yet been written. So in reality, at this point in time "bablRGB" already 
IS UserRGB. There is no reason to write a whole bunch of new babl format 
specifiers for UserRGB. That would be side-by-side implementation.

ALL current babl/GEGL/GIMP editing operations already work just fine, 
regardless of the user's chosen RGB working space, EXCEPT for the fact 
that there are still hard-coded Y and XYZ parameters in the 
babl/GEGL/GIMP code base.

To work with UserRGB data, those hard-coded sRGB Y and XYZ parameters 
need to be generalized to use Y and XYZ parameters pulled from the 
user's chosen RGB working space. If you generalize those operations to 
work with Y and XYZ pulled from UserRGB, those operations will work just 
fine even when UserRGB really is sRGB.

"bablRGB" is now in fact and should remain UserRGB. There is no reason 
to write code that makes "bablRGB" mean "convert to unbounded sRGB" and 
then write more code that means "use UserRGB instead of sRGB".

I'm leaving to one side the babl sRGB TRC flips because that code 
requires special handling, and the user really does need a way to 
completely disable those TRC flips. A fundamental premise for writing an 
RGB image editor is that you never mess with the user's RGB data without 
their explicit permission. Just opening the image with GIMP is NOT 
explicit permission.

Best regards,
Elle Stone