Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/08/2014 10:47 AM, Øyvind Kolås wrote:
> On Wed, Oct 8, 2014 at 4:25 PM, scl <scl gplus gmail com> wrote:
> > Therefore I think it's better to let all operations work on the same
> > appropriate colour space (big enough and computable precisely and
> > efficiently) and do conversions only on the interfaces to the outside
> > world: importing and exporting images, displaying, working with ICC
> > profiles etc. IIRC there was a hint on that in one of the
> > former posts to this topic - what where the reasons to not to do so?
>
> The we have to juggle a large set of different types of pixel formats
> already? The initial thinking was that linear working in RGB and HDR
> was sufficient, that is what the current babl is sufficient for, one
> uses ICC based conversions to get into the internal formats which are
> supposed to have efficient management, programming naming and
> conversions. And uses an external CMS for interacting with the
> outside. As Elle has repeatedly pointed out, that is not sufficient;
> and the scope of what is considered natively juggled pixel formats
> must be extended.

The babl/GEGL/GIMP code base has a relatively short list of places where 
hard-coded sRGB parameters are used. I've already identified most such 
code. Most of it uses sRGB Y values.

To generalize such code to work with all RGB working spaces, replace 
hard-coded sRGB Y values with Y values retrieved by LCMS from the user's 
chosen RGB working space colorant XYZ values. The Y values can be 
retrieved upon opening an image and again upon switching images for 
users who have several images open at once.

The babl conversion to XYZ uses the sRGB D65 color space xy values and 
the D65 white point to convert to XYZ. This results in wrong results 
even for sRGB images in a D50-adapted ICC profile color-managed 
workflow. The right thing to do is retrieve the user's chosen profile's 
colorant XYZ values and ferry that to babl. This takes the place of the 
hard coded (and wrong) D65 sRGB xy values. The equations for converting 
from XYZ to LAB are well known.

I don't understand why replacing the hard-coded sRGB parameters is 
meeting such massive resistance. It's the right thing to do. I don't see 
how it can require more overhead than retrieving the target color space 
information anyway and using it to constantly convert back and forth 
between "sRGB as PCS" and the target color space for the many operations 
that won't work correctly in "sRGB as PCS".

With respect,
Elle Stone