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

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

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

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

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