From: <jos...@ju...> - 2006-06-23 06:22:15
|
= Just a note to all here.. = = Sometime within the next week or three, I may send a very = large evas patch (probably in 3 or 4 parts) which entails a very = *drastic* semantic change for evas --- namely, it will support = only "alpha premultiplied" image data and colors which are given = in argb format. = = This would cause some pain, and break some things.. but in = the long run, I believe it is better. = = However, one has to learn to think in/with "alpha premul" = colors. = = What does this mean???? I'll explain it a bit here. = = 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 >=3D 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' =3D (a*r)/255, g' =3D (a*g)/255, b' =3D (a*b)/255, hence the term = "alpha premultiplied". = = 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. = 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. = |
From: Robin V. L. <rv...@gm...> - 2006-06-23 10:41:53
|
It would certainly break a lot of my code. I currently have some manual bindings of various evas objects to Ruby, and large chunks of code that implicitly require nonpremultiplied alpha. I suppose using premultiplied alpha would also break things like loading ARGB32 data directly from Imlib2 to Evas by hand (I frequently use that method to display images), since IIRC PNG data for example is not premultiplied. Also, I frequently use an 'evas-cairo' object of my own that simply uses an evas image as its surface and responds to cairo calls (I mostly use this for displaying SVGs in Evas and as a fallback for gradients since they got broken in Evas). For this reason I explicitly implemented a de-premultiplier (since cairo uses premultiplied alpha on its surfaces as well). Additionally I have several routines that 'drop-shadow' and 'reflect-shadow' some Evas images by accessing the buffer itself, so that would also break with premultiplied alpha. I wouldn't recommend against it, but I'd highly prefer some global flag which can be set that would allow developers to choose between the two. Or if necessary, a flag on an object-per-object basis that can be overridden if needed. Greets, Robin. On 6/23/06, jos...@ju... <jos...@ju...> wrote: > > > Just a note to all here.. > > Sometime within the next week or three, I may send a very > large evas patch (probably in 3 or 4 parts) which entails a very > *drastic* semantic change for evas --- namely, it will support > only "alpha premultiplied" image data and colors which are given > in argb format. > > This would cause some pain, and break some things.. but in > the long run, I believe it is better. > > However, one has to learn to think in/with "alpha premul" > colors. > > What does this mean???? I'll explain it a bit here. > > 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". > > 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. > 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. > > > > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Simon T. <sim...@fr...> - 2006-06-23 13:43:07
|
Hi Jose, Mm.. It seems to be a very important change indeed. If I understand correctly, it means that all the apps that calls evas_object_color_set() and every edje theme will have to be updated. This is a problem, but it can be quickly solved. The most important problem imho is that "alpha premul" colors are really less intuitive than "normal" colors, at least for me :) For example, when you are designing an edje theme, you often change the alpha of a part to try different values, and to see which alpha value looks the best. So now, every alpha change will need a change of the r, g, b components too, right? Another problem, but maybe I'm wrong on that point, is for transition. A simple example, you want an object to fade out. For now, you only have to use a timer that makes the alpha of the object decrease progressively. It's rather intuive for now. But with this change, you'll also have to update the rgb values, no?! For me, if the only advantage is to avoid some confusion inside the evas's code (so for now, the evas-user is not confused), I think it doesn't worth it. We'll avoid a confusion in the code of evas, but we'll probably confuse the user (i.e. the coder that uses evas). But maybe i'm wrong on the 2 examples I've given, maybe the change is not so important. Regards :) Simon TRENY <MoOm> On Fri, 23 Jun 2006 06:20:47 GMT, "jos...@ju..." <jos...@ju...> wrote : > > Just a note to all here.. > > Sometime within the next week or three, I may send a very > large evas patch (probably in 3 or 4 parts) which entails a very > *drastic* semantic change for evas --- namely, it will support > only "alpha premultiplied" image data and colors which are given > in argb format. > > This would cause some pain, and break some things.. but in > the long run, I believe it is better. > > However, one has to learn to think in/with "alpha premul" > colors. > > What does this mean???? I'll explain it a bit here. > > 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". > > 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. > 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. > > > > 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 enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Simon T. <sim...@fr...> - 2006-06-23 13:58:39
|
And I forgot to mention another problem I have in mind. For now, in edje, if you want to do a color transition from color1="255 0 0 255" to color2="0 255 0 0", you have to create 2 states, the first associated to color1, and the second to color2. With "alpha premul" colors, it will become (if I understand correctly): color1'="255 0 0 255" and color2'="0 0 0 0". So how Edje will guess it has to make a transition from red to green? Or we'll have to keep "normal" colors in edje, but it won't be coherent with the API of evas :/ Simon On Fri, 23 Jun 2006 15:44:42 +0200, Simon TRENY <sim...@fr...> wrote : > Hi Jose, > > Mm.. It seems to be a very important change indeed. If I understand > correctly, it means that all the apps that calls > evas_object_color_set() and every edje theme will have to be updated. > This is a problem, but it can be quickly solved. The most important > problem imho is that "alpha premul" colors are really less intuitive > than "normal" colors, at least for me :) > > For example, when you are designing an edje theme, you often change > the alpha of a part to try different values, and to see which alpha > value looks the best. So now, every alpha change will need a change of > the r, g, b components too, right? > > Another problem, but maybe I'm wrong on that point, is for transition. > A simple example, you want an object to fade out. For now, you only > have to use a timer that makes the alpha of the object decrease > progressively. It's rather intuive for now. But with this change, > you'll also have to update the rgb values, no?! > > For me, if the only advantage is to avoid some confusion inside the > evas's code (so for now, the evas-user is not confused), I think it > doesn't worth it. We'll avoid a confusion in the code of evas, but > we'll probably confuse the user (i.e. the coder that uses evas). > But maybe i'm wrong on the 2 examples I've given, maybe the change is > not so important. > > Regards :) > Simon TRENY <MoOm> > > > On Fri, 23 Jun 2006 06:20:47 GMT, > "jos...@ju..." <jos...@ju...> wrote : > > > > > Just a note to all here.. > > > > Sometime within the next week or three, I may send a very > > large evas patch (probably in 3 or 4 parts) which entails a very > > *drastic* semantic change for evas --- namely, it will support > > only "alpha premultiplied" image data and colors which are given > > in argb format. > > > > This would cause some pain, and break some things.. but in > > the long run, I believe it is better. > > > > However, one has to learn to think in/with "alpha premul" > > colors. > > > > What does this mean???? I'll explain it a bit here. > > > > 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". > > > > 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. > > 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. > > > > > > > > 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 enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > 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 enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: <bri...@gm...> - 2006-06-23 14:21:20
|
On Fri, Jun 23, 2006 at 06:20:47AM +0000, jos...@ju... 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 |