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

[Michael Henning <drawoc darkrefraction com>]

On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> 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.

See below.

> > 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?

To some degree, yes.

We don't need to recreate every single transformation. For example,
when converting from some arbitrary RGB color space to luminance, we
can chain the conversions: first, one conversion from the
user-specified RGB space to linear sRGB, and then from linear sRGB to
luminance. If that's too slow, we also have the option of defining
"fast paths" that convert directly between two color spaces, but the
core of babl always converts to linear sRGB as an intermediate. This
is what we mean when we say "sRGB as PCS": all of the color formats
are defined in terms of linear sRGB, so if a given transformation
hasn't been coded specifically, we can use linear sRGB as an
intermediate.

Also, some portions of sRGB will probably share code with the generic
RGB code. But, the important point is that we want sRGB to still exist
within babl as a usable, built-in format.

> > > 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.

Maybe we weren't too clear.  :P

> 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.

Okay, we should probably look at that then.

From,
  Mike Henning