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

Re: [E-devel] Premultiply or not

On Mon, 26 Jun 2006 06:37:21 GMT,
"jose_ogp@juno.com" <jose_ogp@juno.com> wrote :
>     The get/set functions that deal with image data would
> have to constantly transform from premul to non-premul thus
> making the use of these very slow.. also, if you want to work
> with the data doing graphics ops yourself, then you would be
> better off doing so with it in premul color space, as it's easier
> and faster there.
>     I would say that most here would thus be convinced that
> the evas funcs that set/get image data should thus work with the
> data assumed to be in premul color space.
Yeah, I agree image_data_set/get() could gain from using premul alpha
colors. And since image_data_set/get() is not used really often, or
mainly with alpha=255, it won't break a lot of things.

>     In others, like adding colors to grads, evas could do
> different things -- it could generate the spectrum by linearly
> interpolating in non-premul color space, then premul that for
> compositing, or it could go ahead and transform the inputs
> to premul colors and generate the spectrum from those... These two
> will not give the same results -- not even close if
> there are alphas < 255.
>     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...)

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