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

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?


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