[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, firstname.lastname@example.org 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
> 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.
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
> 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
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.
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)