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

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

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