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:
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.
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list