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

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/09/2014 12:27 PM, Michael Henning wrote:
> On Thu, Oct 9, 2014 at 8:00 AM, Elle Stone
> > I'm not proposing that you use "sRGB as PCS" and then hack the code to fix
> > the resulting problems. I'm proposing that you eliminate "sRGB as PCS"
> > altogether. It's a broken model for RGB editing.
> >
> > The VFX people understood with *one* multiply example that there can be no
> > universal RGB working space. The best working space depends on the artistic
> > intent plus the device(s) that produced the colors, and eventually on the
> > device(s) on which the colors will be displayed.
>
> I'm not entirely clear which concept you're trying to refute in that
> section. sRGB as a PCS, or sRGB as a universal working space? They're
> two different concepts, and while you said sRGB as a PCS, you
> arguments seem to be about sRGB as a working space to me.

My assumption was that "sRGB as PCS" only made sense in the context of 
using unbounded sRGB as a universal working space.

If "sRGB as PCS" means that unbounded linear gamma sRGB is used to 
convert from RGB to XYZ to LAB, for example, then I'm not sure when 
"sRGB as PCS" would be used. For example, for converting to LAB, use the 
user-chosen primaries (colorants) to convert to XYZ and then to LAB.

> Ie, babl will support your suggestion (user-chosen primaries with
> either linear or sRGB TRC) in addition to sRGB, instead of replacing
> sRGB.

Does "in addition to sRGB" mean duplicate code files side by side, one 
set of files hard-coded for just sRGB images and one using Y and XYZ 
values retrieved from the user's chosen primaries? For example, the babl 
code that converts from color to Luminance for painting on a mask would 
be duplicated, once for sRGB and once generalized?

> > Adobe-centric advice implies that color gamut is the only consideration when
> > choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries
> > into their raw processing software. It is distressing to see GIMP follow
> > Adobe's lead by writing code on the assumption that the sRGB primaries are
> > suitable for editing all images.
>
> I'll repeat that the sRGB primaries won't be the only supported
> working space. You talked us out of that idea a long time ago.

Oh. I didn't realize that.

> > The current temperature change code is
> > hard-coded for sRGB images and although it does produce pleasing results for
> > sRGB images, those results are not colorimetrically correct.
>
> I'm not totally clear on this point. Are you saying that it produces
> incorrect results for sRGB, or that it produces incorrect results for
> different color spaces? I'm not too familiar with this part of the
> code.

The temperature change code produces very pleasing results for sRGB 
images, much nicer than another editor that I tried. Based on 
eyedroppering and comparing to spreadsheet calculations, the colors 
aren't colorimetrically correct and maybe they never were intended to 
be. On the other hand, I only checked Bradford adaptation and I'm not 
110% certain I handled all the matrix math correctly.

The current code uses hard-coded coefficients based on sRGB primaries 
and produces obviously wrong results for non-sRGB images. Bradford/CAT02 
etc chromatic adaptation code would seem to be a logical generalized 
replacement.

This article demonstrates using CAT02 to do color temperature 
corrections: http://nbviewer.ipython.org/gist/kelsolaar/7098c6709c59b9afb018
The article uses the D65 sRGB color space, not the D50-adapted sRGB ICC 
profile color space, but it illustrates the math nicely.

Best regards,
Elle Stone