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

[pippin gimp org]

On Sun, Apr 13, 2014 at 08:08:30AM -0400, Elle Stone 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?

Correct, and resampling operations are also mostly implemented with
premultiplied alpha, where the r, g, b values are scaled according to opacity.
This is also encoded by the babl pixel-formats they used.

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

This is true for all formats currently provided by babl; and the processing
currently done by operations, more pixelformats using other RGB chromaticities
might be added in the future. The pixel data would only use these chromacities
locally in the GEGL operation that requests it. To force an override of the
meaning of colors being processes by an operation/node in the data flow graph
of GEGL; you would insert a nodes before/after - that overrides / converts the
pixel values to make the processing happen in a different color model / only
happen to certain components from a given pixel format, or more.

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

This shouldn't be a global choice for the image/composition but a local choice
per layer, the different behavior in compositing means that it is different
layer modes; not different global toggles that changes the behavior of a given
named operation. The current GEGL based processing in GIMP will deal fine with
grayscale layers in RGB images; making the RGB/grayscale setting another global
mode toggle which could be unneccesary.

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

The conversion will be from whichever pixelformat the data already is in at
that stage of the GEGL graph. Temporary buffers and caches for writing results
are created by a gegl node based on the operations desired output (babl)
pixel-format.  When another operation is reading the data into its innerloop
for processing the data is transformed during the copy from the previous ops
desired output format to the consuming ops desired pixel representation.

Thus there is during processing no predetermined format; as soon as some
processing is done on the pixels from the storage format of the raster layers
in GIMP; it is quite likely that the format of the pixels are "RaGaBaA float";
though it might be quite a few others.

One peculiar pixel-format family in Babl is the palette/indexed formats; it is
possible to add icc profile support in a similar manner; but I don't see the
large benefits form the added complexity over over using lcms2 at the edges of
the graph on import/export; and maybe for specific local overrides during
processing.

/pippin