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

Re: [E-devel] Evas and alpha premul color data



On Fri, Jun 23, 2006 at 06:20:47AM +0000, jose_ogp@juno.com wrote:
>   
> 	In argb color space where colors are specified by 4-tuples  
> a, r, g, b, representing the alpha, red, green, and blue components  
> of a color, that this is an 'alpha premul' color means that the  
> alpha component 'a' has value >= the r,g,b components.  
>   
> 	That's all it means, nothing more.  
>   
> 	One way to obtain an alpha premul color from any color,  
> is to replace the old r,g,b values by new r',g',b' values given by  
> r' = (a*r)/255, g' = (a*g)/255, b' = (a*b)/255, hence the term  
> "alpha premultiplied".  

So, basically you're going from a coordinate space with an orthogonal
basis to one that isn't? I can see how this might simplify internal
routines, but I don't think it makes any sense for the API to use. This
would require any application that changes the alpha of an object to
also change the r,g,b components. E.g. the following would not be
possible:

int r,g,b;
Evas_Object *o = give_me_my_object();
evas_object_color_get(o, &r, &g, &b, NULL);
evas_object_color_set(o, r, g, b, 120);


With a premul API, you'd have to do somthing like:

int r,g,b,a;
int new_a = 120;
Evas_Object *o = give_me_my_object();
evas_object_color_get(o, &r, &g, &b, &a);
r *= ((double)new_a/a);
g *= ((double)new_a/a);
b *= ((double)new_a/a);
evas_object_color_set(o, r, g, b, new_a);


For image objects, would you have to do that for every pixel also?
Or would you just color_set(120, 120, 120, 120)?


I'm not sure I see the benefits of this. The conversion should be done
internally IMO.

>   
> 	Where will evas be affected by this? Anywhere you see image  
> or gradient objects take argb32 data... this data will now be  
> *assumed* to be alpha premul by default. If you pass in data, or  
> specify colors, that are *not* premul, then you will get mostly  
> junk results.  

This is mostly a matter of changing loaders, which wouldn't affect most
apps. However, a few use ARGB data from imlib2 which isn't premul
(elicit, e.g.).


> 	Similarly, any api function that refers to setting a color  
> on an object somehow, it will now be assumed that the color is  
> alpha premul.. If they aren't, you will get mostly junk results.  
>   
> 	"Why not simply keep the interfaces to accept non premul  
> colors, as is now the case, and just do things internally with  
> premul if that's such a great thing...?"   
>   
> 	Because mixing premul and non-premul color spaces leads to  
> immense amounts of confusion, and is error prone..  
> 	I have seen very knowledgable and experienced people get  
> wrapped around in the confusion caused by this.  
>   
> 	Learn to think with alpha premul colors, this may seem  
> drastic.. and it is indeed.. but it's far more consistent for a  
> wide variety of things, and even more 'natural' once one gets used  
> to the change.  
>   
>   
> 	If this change seems unacceptable to most here - and I can  
> certainly understand that - or would prefer some mixture of premul  
> and non premul... that's fine, I will leave evas alone then.  
>   
> 	But I personally want nothing to do with mixing these two  
> color spaces. It's a bad idea.  
>   
>   
>    jose.  
>   
> 

Being used to something always makes it feel 'natural'. (Hell, vim feels
natural to me... doesn't mean it is) :)
Can you elaborate a bit more on what the benefits would be? So far, it
sounds like only internal evas development would benefit. External usage
would now have to deal with the fact that the colorspace componenents
aren't orthogonal. Not difficult, but extra work on the outside of the
API.

--
rephorm