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

Re: [E-devel] Premultiply or not



On Mon, Jun 26, 2006 at 06:37:21AM +0000, jose_ogp@juno.com wrote:
> 
>     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.
> 
>     However, when it comes to the funcs that deal with just
> single colors, most seem to be reluctant to come to a similar
> conclusion.
> 
>     There are several functions that deal with setting
> individual colors - setting an obj's color, setting the text
> style colors, adding colors to grads, ... and there are likely
> to be more to come.


I'm starting to come around, but am still slightly hesitant. I think
there are two ways you can view the colors in question.

A) Color of a 'physical' canvas object that has a separate
'transparency' property. "Graphic Artist"

B) The color of the individual pixels that gets drawn to the screen.
"Graphic Programmer"

In (A) we are thinking in non-premul terms. E.g. we have a green
rectangle (rgb = 0 255 0) that is then faded to 50% (a = 128). So, we
think combine these into argb = 128 0 255 0.

However, what is ACTUALLY happening (as you've pointed out), is that the
opaque object has argb = 255 0 255 0, and the fading to a=128 applies to the
color vector as a whole. e.g argb = 128 0 128 0.  This view is more closely
related to (B).

As an (illustrative?) aside, an interesting case: antialiased text. We tell
some text that we want to be green that it has a color of 255 0 255 0. For the
opaque parts this is true in both models. Now, the AA parts of the text
have alpha < 255. Currently, we think of this as just affecting the
alpha bit of the pixel. So, every pixel fo the text (in non-premul
terms) has rgb = 0 255 0. In premul terms the 'rgb' piece of the color
vector is no longer constant throughout the text. Anyway, just an
interesting difference between the two color models.

> 
>     In some of these, evas cannot directly use the non-premul
> colors in any way, so it would just transform the input color to
> a premul one. The only effect these have is thus one level of
> indirection -- what you input is not really what gets used.
> 
>     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 a lot of these, we might need two sets of API functions. Of course,
we then get to argue over which is 'default' (e.g. which does
evas_object_color_set() use). For grads, if specified in non-premul
terms, that means build the spectrum entirely in non-premul THEN
convert.

>     I can't see any benefit to having the inconsistency
> of data get/set being premul but color get/set being non-premul.
> All I see is indirection and untold confusion and limitations
> arising from this latter.
> 
>     One could put any use of non-premul colors up to
> 'higher level' libs if they find interfacing with non-premul
> colors to be "good" somehow...
>     In particular, we might think that edje would benefit
> from this.. and indeed Simon has pointed out an example where
> it would seem to be easier to have non-premul colors in the
> edc format: the use of "linear transitions" from one color
> to another to set an object's color.
>     If edje were to use premul colors, then such transitions
> would seem to be difficult to obtain....

This makes sense to me. Evas is (essentially) a compositing engine, so
the colors it uses should be described in compositing (premul) terms.
But edje is a graphic design tool, so its colors should be described in
'normal' (non-premul) terms. I gaurantee you you're not going to
convince designers to use premul colors. They don't make sense in the
"green object with fifty percent transparency" mindset.


> 
>     Well, they could be approximated by several linear
> transitions, if edje/edc were to work with premul colors only..
> but this may seem like to much work for some.
> 
>     However, there are better ways.
> 
>     One thing you should realize is that these "linear"
> transitions are not really linear at all in the resulting
> display color space if there's alpha involved.. and in fact
> it would be impossible to obtain linear transitions of premul
> colors.

Sure, but again they ARE linear if you're thinking about 'color' and
'opacity' as separate properties. This may be an abstraction of what is
actually going on, but a very natural abstraction.

>     If you really want to have this capability, and extend
> it to something more powerful as well, then it would be easy
> to do with edje/edc using premul color space.
> 
>     We can add "quadratic" transitions (or even any spline
> based one), all one needs to specify this would be the start and
> end colors of course (premul now), c0, c1 say, and a 'control'
> color cc say.
>     The premul color at a given time t, for t in [0,1], is
> then given by:
>     c(t) = t*t*c1 + 2*t*(1-t)*cc + (1-t)*(1-t)*c0;
> 
>     This would give you all the capabilities of the current
> non-premul case... and more.
> 
> 
>     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.
> 
> 
>   jose.
> 
> 

Maybe the 2.5 case you mentioned above? Evas in 100% premul terms and
edje / higher level apis not? (or 2.25 - which includes an additional
non-premul api to evas for convenience)

--
brian