On Mon, Jun 26, 2006 at 06:37:21AM +0000, [EMAIL PROTECTED] 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 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
