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

[pippin gimp org]

On Sun, Apr 13, 2014 at 06:18:08AM -0400, Elle Stone wrote:
> On 04/12/2014 06:45 PM, Øyvind Kolås wrote:
> > On Fri, Apr 11, 2014 at 11:54 PM, Elle Stone
> > <ellestone ninedegreesbelow com> wrote:
> > > On 04/09/2014 06:36 PM, Elle Stone wrote:
> > > > For Lighten only, Darken only, Multiply, Divide, and some of the other
> > > > blend modes, results are *highly dependent* on the color space in which
> > > > the blending is done. Removing clipping code doesn't fix the problem.
> >
> > 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 think you might be using the phrases "color space" and "working
> space" in a way that, although technically correct, perhaps might be
> confusing to a lot of people.
>
> My understanding of what you mean by "color space/working space" is
> as follows:
>
> 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.

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.

> 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; for
better communication than what is possible by email please try IRC.

/pippin