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

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.

Kind regards,
Elle Stone

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