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

[Jon Nordby <jononor gmail com>]

On 5 November 2014 14:50, Elle Stone <ellestone ninedegreesbelow com> wrote:

> On 11/05/2014 08:22 AM, Jon Nordby wrote:
>
> >     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.
> >
> >
> > No it is not. There will be one implementation of say "multiply". It
> > will be able to work on any RGB color space. Including sRGB, but without
> > need for special casing.
> >
> >     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".
> >
> >
> > The meaning of the "bablRGB" specifiers has not, and will not change.
> > The vast majority of operations will just stop using them (because they
> > have hardcoded sRGB parameters), and instead use the new specifiers, as
> > per the roadmap.
> For the babl code that converts an sRGB image to grayscale for use as a
> layer mask, do you plan to add a new set of functions that convert from
> UserRGB to grayscale?
>
> That code would, of course, need to pull Y values from UserRGB. Which of
> course means that the new code for UserRGB would also work for sRGB images.
>
> For the babl code that converts from color to Y for painting on a mask,
> that code currently is hard-coded to use sRGB Y values. Do you plan to add
> a new set of functions that convert from UserRGB to Y for painting on a
> mask? That code would also, of course, need to pull Y values from UserRGB.
> Which of course means that the new code for UserRGB would also work for
> sRGB images.
>
> For all the GIMP UI functions that currently use hard-coded sRGB Y values
> sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of
> alternate functions that will use Y values pulled from UserRGB? Again, that
> new UserRGB code will also work for sRGB images.
>
> How is this not side-by-side implementation?

When I said "operations" I meant GEGL operations: There will be no
side-by-side implementation of GEGL operations.
Yes, we will have to introduce new babl color conversion functions which
handle arbitary RGB color spaces by looking up parameters from UserRGB.
Both to convert from&to grayscale and between the various RGB spaces. There
is no escaping that, as we don't have any code that can handle these cases
right now.

Whether the existing conversion functions with hardcoded sRGB parameters
for bablRGB will remain once general functions exists, is an open question.
It could be that they will just call into the general RGB color conversion
functions with the particular parameters of sRGB.
Or it could be that keeping the functions as-is has benefits that outweigh
the cost of keeping the code around, like being able to do performance
optimization tricks not possible in the general case.

What part of the latest new plan am I missing? Could you explain the
> purpose that is served by having all the functions with hard-coded sRGB
> parameters sit side by side with equivalent functions that use UserRGB
> parameters?
>
> Or are you really getting rid of *all* the hard-coded sRGB parameters? In
> which case, what is the new purpose for the bablRGB formats that "will not
> change" their meanings?

For operations which have an actual dependency on sRGB parameters, like the
previously mentioned operations emulating color blindness. Or for
interacting with (sometimes broken) operating-system/library interfaces
which expects sRGB. I don't expect it to be particularly common.
The primary reason (as I see it) for not changing the semantics of existing
specifiers is to preserve compatibility. Code outside of BABL/GEGL/GIMP
could very well be reliant on the current meaning of the bablRGB formats.



-- 
Jon Nordby - www.jonnor.com