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

[Elle Stone <ellestone ninedegreesbelow com>]

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?

Why would any sane developer want to write all the new code and have it 
exist side by side with equivalent hard-coded sRGB functions?

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?

Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography