GNOME.org
 

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

You are correct in the sense that *right now*, most of the babl color
spaces are based on the sRGB chromaticities. There is nothing
preventing us from adding different color spaces in the future,
including ProPhoto RGB.


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?


No, not always. Gimp already has the option of storing your image in a
linear or perceptual gray color space, as well as different indexed
formats. As above, new formats can be added easily. Can I ask: what
difference does it make? If I convert an image from ProPhoto to
CIELAB, or if I convert from sRGB to CIELAB, I will get the same
result. The gegl operation doesn't care how the data is stored; it
only cares what format it receives the data in.

On Sun, Apr 13, 2014 at 8:08 AM, Elle Stone
<ellestone ninedegreesbelow com> wrote:

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

_______________________________________________
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]