Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB

[Elle Stone <ellestone ninedegreesbelow com>]

On 04/13/2014 06:41 AM, pippin gimp org wrote:
> On Sun, Apr 13, 2014 at 06:18:08AM -0400, Elle Stone wrote:
> > In the strongly color-managed world of BABL and GEGL, the only *RGB*
> > color space/working is *s*RGB, either the linear gamma/light sRGB or
> > the more perceptually uniform regular sRGB with its not quite
> > gamma=2.2 TRC.
>
> There is no linear gamma *or* perceptually uniform choice at import. There is a
> conversion to one of the babl-managed pixel formats; and after that GEGL
> operations are free to convert between any of the unbounded babl formats.

I didn't mean to imply that there was a choice of which TRC to choose 
upon import. The plan seems to be that when GIMP 2.10 is released the 
image will be converted from its source color space to a color space 
with the sRGB chromaticities.

Whether that sRGB color space is actually linear gamma sRGB or sRGB with 
the regular sRGB tone reproduction curve is a separate question. You are 
saying that which TRC is used depends on the operation in questions. For 
example currently heal and drawing a gradient are done using the sRGB 
TRC. And Scale, Gaussian blur, and Unsharp Mask are done using the 
linear gamma TRC. Yes?

The point is that when GIMP 2.10 is released, regardless of what happens 
to the TRC upon import, the *chromaticities* used for all further 
processing will be the sRGB chromaticities, NOT the chromaticities of 
the source color space. This point has been confirmed several times.

> GIMP is making things more confusing by letting an arbitrary extra parameter
> change the behavior of compositing ops; this "feature" is something I consider
> a bug, it shouls also be considered bugs to do operation in linear space if the
> algortihm of a GEGL op behaves incorrectly/really unexpectedly unless it works
> in a more perceptual space.

OK, so in the interests of consistency, the limited current choice 
between allowing an operation to happen in the linear gamma sRGB color 
space vs the more perceptually uniform regular sRGB color space should 
be eliminated, yes? You consider this UI user choice to be a bug, yes?

> > I've asked this question of what is actually meant by "color
> > space/working space" in the world of BABL and GEGL twice before now,
> > and no one has answered. But it's a pretty important point, so I'm
> > asking again.
> >
> > Thanking you in advance for confirmation/clarification of what
> > "color space/working space" means when discussing *BABL/GEGL* color
> > spaces/working space,
>
> Not sure if this is a clarification; I do not know what you mean by the terms
> either and can only tell you what the intended architecture of GEGL is


> > sRGB converted to CIELAB.
> > sRGB converted to HSL.
> > sRGB converted to HSV.
> > sRGB converted to CMY(K).
> > sRGB converted to Gray.
> > sRGB converted to YCbCr.
> > sRGB converted to some other model of color space, such as XYZ or
> > CIELUV, for which code might be written at some point in the future.


In the folder babl/extensions, see ycbcr.c, naive-CMYK.c, grey.c, HSV.c, 
HSL.c, CIE.c. These conversion are between the sRGB RGB color space and 
various other color space models, namely CIELAB, HSL, HSV, CMY(k), Gray, 
and YCbCr.

The sRGB TRC is assumed in many places in the BABL code. To see what I 
mean, do a command line search in the babl source code folder:

find -name "*.c" -or -name "*.h" | xargs grep -H "gamma_2_2" {} \;

The sRGB chromaticities are assumed in various places in BABL, GEGL, and 
GIMP. Do a search for the word LUMINANCE, although some places have the 
values hard-coded.

> > The key point is that the chromaticities of the *RGB* color space, that
> > might be converted to some other *model* of color space, are *always*
> > the *s*RGB chromaticities.

There is no provision for converting from some other RGB color space to 
these other color models. The only provision is for converting from sRGB 
to these other color space models.


On 04/12/2014 06:45 PM, Øyvind Kolås wrote:>
> You seem to be under the impression that all processing whatever the
> operation is done going to happen in one color space/pixel format a
> "working space". In a GEGL processing world; it is the individual
> operations that have working spaces; there is no global working space
> that things happen in. (NB: having gamma toggles in blending modes of
> GIMP is according to this model making things confusing, compositing
> in different color spaces should be _different_operations_).
I do think I understand what you are saying. Gaussian blur, Unsharp 
Mask, and Scale are examples of operations that give technically 
incorrect results when done in a nonlinear RGB color space. So you are 
saying GEGL/GIMP shouldn't allow the choice to perform these operations 
in the regular sRGB color space with its almost perceptually uniform 
TRC, yes? Rather they should only be done in linear gamma space, which 
is actually how it works right now.

And if the operation is better done in in some other color space 
*model*, not RGB but rather perhaps CIELAB or HSL or whatever, then the 
conversion is now and will always be from *sRGB* to CIELAB, HSL or 
whatever, yes?

Elle