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

[Gez <listas ohweb com ar>]

El dom, 13-04-2014 a las 00:45 +0200, Øyvind Kolås escribió:
> 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_).

Does this mean that some operations (a multiply or divide blend, for
instance) will be done in another pixel format where out-of-sRGB-gamut
values don't necessarily mean out of bounds values (negative or >1,
hence problematic for certain operations) in channels?

I think that what Elle is asking is about the RGB operations that break
with ubounded sRGB chromaticity values. Several operations don't seem to
be suitable for chromaticity values beyond the 0,1 range.

Gez