Re: Some blend modes break in unbounded mode sRGB

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

 



El dom, 13-04-2014 a las 19:25 +0200, Øyvind Kolås escribió:
> On Sun, Apr 13, 2014 at 7:17 PM, Michael Natterer <mitch@xxxxxxxx> wrote:
> > On Sun, 2014-04-13 at 13:01 +0000, pippin@xxxxxxxx wrote:
> >> 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.
> >
> > Um? I don't see much premultiplied processing around.
> >
> > It's mostly "RGBA float" or "R'G'B'A float" isn't it?
> 
> gaussian-blur, whirl/pinch, scaling, warp tool, pixelize, and most
> compositing modes are using "RaGaBaA float" if they used "RGBA float"
> instead their innerloops would have to take alpha weighting into
> account to avoid color bleeding from transparent pixels into opaque
> pixels.
> 
> /pippin

I can see the associated/unassociated alpha and linear/gamma switches
are in place and I think all of it makes sense (maybe there are places
in GIMP where those switches don't work properly yet, but that's not the
question)

What I still can't understand is how unbounded values will be managed in
some RGB operations that don't work well with negative values, and none
of the answers in this thread seem to clarify it.

There are several examples, but the simplest situation I can think of
are the multiply/divide blend modes.
A simple operation like multiplying cyan*red (0,1,1*0,0,0) breaks when
those red and cyan comes from a wide-gamut colorspace and have been
converted to unbounded sRGB.
I tried with a wide-gamut profile where red and cyan converted to
unbounded sRGB had these values:
RED: 1.6548, -0.1319, 0.0052
CYAN: -0.6548, 1.3290, 0.9948

Note that those values are perfectly complementary and if you add them
together you'll get white as expected, but the result of multiplying
them goes completely bonkers:

-1,0835 -0,1492 0,0051

That should be black. Neither clamping or clipping will give black.
Ok, it's pretty close to black if you clip the result, but it still has
a little blue that shouldn't be there, and that will accumulate through
the composite.

How are cases like these managed using unbounded sRGB? multiply/divide
are basic operations that are present in several blending modes.
Is this a problem or I got it all wrong?

If this is a stupid question please let me know so I stop asking :)

Gez.

_______________________________________________
gimp-developer-list mailing list
List address:    gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list





[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux