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

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

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.


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

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