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

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

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

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

This article demonstrates using CAT02 to do color temperature corrections:
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.

  Mike Henning

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