[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Premultiply or not
> > There are ways to approximate the first using the second,
> > but not the other way around... so, using non-premul colors
> > directly is actually a restriction on what can be obtained.
> For grads, I would have thought that using premul colors was
> actually more restrictive than using non-premul colors, mostly
> because the conversion from non-premul to premul colors is not
> reversible (i.e if alpha=0, you can't get back the original
> non-premul color from the converted premul color).
> So, how can you make a linear grad from "opaque red" to
> "transparent green" with premul colors? With non premul colors,
> you just have to add 2 colors to the grad: "255 0 0 255" for
> "opaque red" and "0 255 0 0" for "transparent green". In premul
> colors, there is no "transparent green" (well... I agree,
> "transparent green" is visually the same color than "transparent
> red", since it's all transparent...)
It seems this way mainly because everyone is so used to
using non-premul colors (due to legacy stuff and whatnot).
This is somewhat subtle, but in short no you can't make
a gradient from opaque-red to transp-green with premul colors
using just *two* colors.
You can do it (arbitrarily close) by using more premul
colors, but not just two. It's the same thing as the 'transition'
case you brought up.
The use of non-premul colors for this is mostly just
a convenience to obtain said results "easily".
But it has a heavy price: It creates all sorts of
confusion and it makes it impossible to do real linear gradient
spectrums with premul colors.
As I mentioned in a previous later, I went into this
very issue on the cairo list recently.. you can check that thread
out if you're interested in this a bit.
> > In conclusion -- as I see it, there are three possible
> > paths for "e" as a whole to follow when it comes to this issue
> > of premul or non-premul color spaces.
> > 1. Do nothing - remain with using non-premul as is now
> > currently the case.
> > 2. Move the internals of the graphics stuff to premul,
> > but leave all, or most, of the interfaces to use non-premul.
> > 3. Move as much of elibs/eapps as feasible to use premul
> > color space.
> > I have tried to give my view above of some of the pros
> > of going with 3, and why I don't want anything to do with 2.
> I'd rather be for solution 2, i.e. keep all the API functions
> use non-premul colors, except image_data_set/get().
> Simon TRENY <MoOm>
That's raster's favorite as well, and it was mine too
until very recently... until I started looking into this in more
Not anymore for me. I just sense this to be a bad idea
whose only merit is to bring future problems just to cause less
pain for current stuff. This is a recurring issue that seems
to feed on itself :(