Re: [Gegl-developer] [Gimp-developer] babl roadmap

[Elle Stone <ellestone ninedegreesbelow com>]

FYI, I'm not interested in continuing this discussion with Pippin.

Twice it seemed that unbounded sRGB would be abandoned and that 
"sRGB-only" would be reserved for only those very few and easily 
identified RGB editing operations that really only could work in the 
sRGB color space.

In my opinion, babl/GEGL/GIMP together make a great combination. The 
only thing I'm objecting to is Pippin's desire to shoehorn into the mix 
unbounded sRGB for RGB image editing.

Right now I use three side-by-side babl/GEGL/GIMP installations for 
image editing, one each for the three different RGB working spaces that 
I use regularly (guess what, one of them is for sRGB).

For each installation I changed the hard-coded Y values to match the Y 
values of the intended RGB working space (the GIMP hard-coded sRGB Y 
values are not correct, being D65 unadapted values). And I disabled the 
babl TRC flips.

I don't ever use the XYZ-to-LAB conversion. Nor do I use the 
YCbCr/YIQ/color-temperature and so forth code. So all I needed to change 
to get accurate RGB editing operations was the hard-coded Y values.

I have already posted a bug report and a write-up on how to fix GIMP 
color management, containing a (hopefully) complete list of all 
hard-coded sRGB and NTSC parameters:
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html
https://bugzilla.gnome.org/show_bug.cgi?id=737778

I have tried to explain the problems shoehorning unbounded sRGB into the 
babl/GEGL/GIMP code base will cause.

But unless some of the developers want to start a branch that won't use 
unbounded sRGB, I think it's time to stop the conversation.

Unfortunately I don't know how to ferry UserRGB Y values to the places 
in the babl/GEGL/GIMP code that currently use hard-coded sRGB Y values. 
Otherwise I would submit a patch. But I did submit code for retrieving 
UserRGB Y and XYZ values.

Kind regards,
Elle Stone