Re: [E-devel] Premultiply or not
On Thu, 7 Sep 2006 10:38:20 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Anyway... I think it might be best to let the edc format stay as it is (non-premul colors), and have edje do the conversion, not edje_cc. If desired, a later edje can have other types and/or versions of 'design-formats', like edc, and one can do whatever.. There are possibilities for things that are very interesting with premul colors, and having evas handle premul colors, as given, would allow for that. agreed - now i have had time to mull. break the color_set - make it premul. we have anon-premul-import for convenience, and we modify all the code we can 0 edje converts at runtime before color_set when using config valued in the .edj. ;) Ok, I'll try and finish things off over the weekend and see if I can send it over Mon or Tues. I'm not satisfied with the premul vs non-premul color_set issue either.. it sucks either way for one reason or other. yup - but i think we need to bite the bullet. color_set needs to be premul as thats the api-level colorspace. :( sucky eh? :( For the eet and edb image loaders.. evas will convert to premul from what they serve and leave eet/edb themselves alone -- or do you want to change those as well? for now - evas will convert. i will move them to be premul on-disk - later. i will need to bump the version of them internally (add flags) so we will need the premul it for me code anyway. :) - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, 4 Jul 2006 04:18:18 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Jose writes: correct. non-premul to premul is destructive. VISUALLY it will look the same when composited, BUT this should be an understanding - correct. Yes, that's right. It destroys the superflous information that may be contained in the overdetermined inputs - as far as the actual compositing is concerned. I should add that this is also one reason why we want to work entirely in premul color space - so we don't have to premul anything, we just assume the inputs to be so and simply use them as given. If one instead assumes the inputs to be non-premul, then one has to, at the compositing stage, premultiply them -- what you input is not really what gets used for compositing. Carsten writes: well actually i was thinking ALL engines would use premul ARGB by DEFAULT unless you tell them that you want to get/set pixel data in another colorspace (yuv, yuva (planar, interleaved etc.), non-premul argb etc. etc.). IF the engine CAN handle the format natively (eg some yuv formats if we have xvideo accel) then the engine will avoid any conversion internally and deal with it as-is. if it cannot - then it will convert as needed internally. What engine is going to handle non-premul argb natively? That's what evas' software engines do right now, and creates the inconsistency with the render engine. You can't perform transforms in non-premul color space and expect to obtain the same results as similar transforms in premul color space. You are mixing two different kinds of things here - yuv vs rgb is NOT the same thing as premul vs non-premul. i know - engine are allowed to make approximations though - it is valid :) i am talkign theory here though. *IF* the destination targets can't do rpemul the engine will have to convert to non-premul just like the xrender enigne converts to premul... :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, 4 Jul 2006 00:47:52 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Let's agree on one thing: The gfx operations, unless otherwise explicitly stated, will be done in premul argb color space, or a linear equivalent of it.. agreed - with possible FUTURE ability to use more esoteric colorspaces like YUV (though frankly yuv is handled most sanley by a convert to yuv first - BUT you can actually get speedups combining the scale and convert at the same time) Ok good, at least we're getting somewhere :) Ok, fine.. and actually premul ayuv would be ok too since when decoded yuv is linearly related to rgb (hsv eg. is not). There's already such an interface to set imported data from yuv, and moving the 'conversion' to rgb down to the engines is fine as they may simply be able to deal with it directly, etc.. That's all good, and an interface for importing yuv to image data is already there, you can extend it to cover any premul ayuv format type with no problem. sure - and i would suggest we expand it to also import non-premul ARGB - thats basically all i was really suggesting. :) That would be the best way to do it, yeah :) Let's assume that edje has been modified to pass premul colors/data to evas, and eet saves premul data, and that evas provides premul/non-premul conversion api functions for colors data.. Just where exactly in e17 would there be even minor pain caused by evas being premul only? every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) Ok I looked at the e17 ones. Nearly all of them are of two kinds: either setting a color that's already premul (usually opaque white or transp black), or for defining some smart-class' color-set callback. Neither case needs anything done (color-set smart callbacks would expect premul inputs). That leaves about 6 left I think. Anyway... I think it might be best to let the edc format stay as it is (non-premul colors), and have edje do the conversion, not edje_cc. If desired, a later edje can have other types and/or versions of 'design-formats', like edc, and one can do whatever.. There are possibilities for things that are very interesting with premul colors, and having evas handle premul colors, as given, would allow for that. agreed - now i have had time to mull. break the color_set - make it premul. we have anon-premul-import for convenience, and we modify all the code we can 0 edje converts at runtime before color_set when using config valued in the .edj. ;) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Mon, 3 Jul 2006 23:19:05 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Tue, 4 Jul 2006 00:11:10 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) Etk doesn't often use evas_object_color_set() so it will be really easy to port. For .edc files, I really think the colors should remain non-premul RGBA colors since .edc files are made by graphic designers, and designers are used to non-premul RGBA colors (graphic tools give non-premul colors). And using premul colors will really make theming painful imho since themers often try different color settings to see which setting is the best looking. With premul colors, the themers would have to convert to premul colors each time they would like to change a color. that's a good point. i guess .edc's should stay non-premul. i would then say - convert runtime as converting JUST colors is really simple and painless and it's not going to be overhead worth worrying about. Now, whether edje_cc should convert to premul on compilation or do it on runtime, I don't really know. Maybe it could be done during the compilation, so it'll save some work during runtime. Also, what do you think of having an API like that for image_data_set/get()? void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace); void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing); actually i was thinking void evas_object_image_colorspace_set(Evas_Object *obj, Evas_Colorspace colorspace); Evas_Colorspace evas_object_image_colorspace_get(Evas_Object *obj); the setting of the colorspace will then determine the ARGB pixel format you set or get (and also then allow setting of YUV too later trivially with direct access). this would not break the api at all :) The colorspace param in the data_set() func describes the colorspace of the given data, and in data_get(), it describes the colorspace in which you'd like to get the data. The colorspace in which it's stored by Evas could depend on the engine (it could be colorspace if the engine is optimized for colorspace, or another more adapted colorspace). Perhaps that is what you were already discussing with Jose, I haven't understood very well. well actually i was thinking ALL engines would use premul ARGB by DEFAULT unless you tell them that you want to get/set pixel data in another colorspace (yuv, yuva (planar, interleaved etc.), non-premul argb etc. etc.). IF the engine CAN handle the format natively (eg some yuv formats if we have xvideo accel) then the engine will avoid any conversion internally and deal with it as-is. if it cannot - then it will convert as needed internally. Regards, Simon TRENY MoOM -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Mon, 3 Jul 2006 15:17:18 -0500 [EMAIL PROTECTED] babbled: On Tue, Jul 04, 2006 at 12:11:10AM +0900, Carsten Haitzler wrote: On Sun, 2 Jul 2006 23:57:15 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: But, setting a color space, either globally or per obj, has only one real meaning - that the color space in question is going to be used as the current context for gfx ops. oooh no - for me it means that became the api with which u dealt with evas. evas internally would do whatever it damn well pleased. :) the only guarantee u had is that u could present data in format X and get it back in format X. what happend later was entirely out of scope and goign to happen in premul ARGB. With the added stipulation that the data returned may not be exactly the data given (due to colorspaces not mapping 1-1 on each other). Unless you plan on keeping the untouched data around somewhere (which would double the memory usage). correct. non-premul to premul is destructive. VISUALLY it will look the same when composited, BUT this should be an understanding - correct. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
Let's agree on one thing: The gfx operations, unless otherwise explicitly stated, will be done in premul argb color space, or a linear equivalent of it.. agreed - with possible FUTURE ability to use more esoteric colorspaces like YUV (though frankly yuv is handled most sanley by a convert to yuv first - BUT you can actually get speedups combining the scale and convert at the same time) Ok good, at least we're getting somewhere :) Ok, fine.. and actually premul ayuv would be ok too since when decoded yuv is linearly related to rgb (hsv eg. is not). There's already such an interface to set imported data from yuv, and moving the 'conversion' to rgb down to the engines is fine as they may simply be able to deal with it directly, etc.. That's all good, and an interface for importing yuv to image data is already there, you can extend it to cover any premul ayuv format type with no problem. sure - and i would suggest we expand it to also import non-premul ARGB - thats basically all i was really suggesting. :) That would be the best way to do it, yeah :) Let's assume that edje has been modified to pass premul colors/data to evas, and eet saves premul data, and that evas provides premul/non-premul conversion api functions for colors data.. Just where exactly in e17 would there be even minor pain caused by evas being premul only? every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) Ok I looked at the e17 ones. Nearly all of them are of two kinds: either setting a color that's already premul (usually opaque white or transp black), or for defining some smart-class' color-set callback. Neither case needs anything done (color-set smart callbacks would expect premul inputs). That leaves about 6 left I think. Anyway... I think it might be best to let the edc format stay as it is (non-premul colors), and have edje do the conversion, not edje_cc. If desired, a later edje can have other types and/or versions of 'design-formats', like edc, and one can do whatever.. There are possibilities for things that are very interesting with premul colors, and having evas handle premul colors, as given, would allow for that. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
With the added stipulation that the data returned may not be exactly the data given (due to colorspaces not mapping 1-1 on each other). Unless you plan on keeping the untouched data around somewhere (which would double the memory usage). correct. non-premul to premul is destructive. VISUALLY it will look the same when composited, BUT this should be an understanding - correct. Yes, that's right. It destroys the superflous information that may be contained in the overdetermined inputs - as far as the actual compositing is concerned. In every situation when compositing is involved, premul colors are the way to go, and when it's desired to have a separate means to control 'alphas', then a separate alpha-mask is the way to do it. A similar mechanism should be used for all color+geometry related aspects -- eg. as Keith Packard suggested, separate alpha- stops for gradients, and I would do similarly for setting colored vertices for paths, etc. It's either that, or the 'geometry' needs to be further subdivided. In the 0-dim case of just a single 'multiplier' color in isolation, giving a separate alpha value would be superflous, so might as well let the color be premul to begin with. All the holy specs of svg, pdf, etc. (and maybe even OpenGl), who believed that giving non-premul color data for 'vertices' as a means to allow for interpolation that would otherwise be difficult or impossible with premul color inputs... have screwed up, and are taking everyone else along for the ride. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
Jose writes: correct. non-premul to premul is destructive. VISUALLY it will look the same when composited, BUT this should be an understanding - correct. Yes, that's right. It destroys the superflous information that may be contained in the overdetermined inputs - as far as the actual compositing is concerned. I should add that this is also one reason why we want to work entirely in premul color space - so we don't have to premul anything, we just assume the inputs to be so and simply use them as given. If one instead assumes the inputs to be non-premul, then one has to, at the compositing stage, premultiply them -- what you input is not really what gets used for compositing. Carsten writes: well actually i was thinking ALL engines would use premul ARGB by DEFAULT unless you tell them that you want to get/set pixel data in another colorspace (yuv, yuva (planar, interleaved etc.), non-premul argb etc. etc.). IF the engine CAN handle the format natively (eg some yuv formats if we have xvideo accel) then the engine will avoid any conversion internally and deal with it as-is. if it cannot - then it will convert as needed internally. What engine is going to handle non-premul argb natively? That's what evas' software engines do right now, and creates the inconsistency with the render engine. You can't perform transforms in non-premul color space and expect to obtain the same results as similar transforms in premul color space. You are mixing two different kinds of things here - yuv vs rgb is NOT the same thing as premul vs non-premul. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Sun, 2 Jul 2006 23:57:15 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: we need the ability to have image objects in different colrospaces yugv(and its variants, yuv422, yuv420, etc. etc.) is a long-term must. the ENGINE has to deal with yuv data. if it can't it can always use the yuv import calls internally to RGBA then do it all in RGBA land - but if the subsyetm (gl/xrender/etc.) can do yuv natively - then do it that way, hoping the hw accel does a much better job than we do. adding in ARGB non-premul as another colorspace is merely convenience as its just the SAME logic as handling a yuv image object - having to convert to a native format before using it. in fact its probably the thing we would want to test with to start with. yuv would get support later. Let's agree on one thing: The gfx operations, unless otherwise explicitly stated, will be done in premul argb color space, or a linear equivalent of it.. agreed - with possible FUTURE ability to use more esoteric colorspaces like YUV (though frankly yuv is handled most sanley by a convert to yuv first - BUT you can actually get speedups combining the scale and convert at the same time) Ok, fine.. and actually premul ayuv would be ok too since when decoded yuv is linearly related to rgb (hsv eg. is not). There's already such an interface to set imported data from yuv, and moving the 'conversion' to rgb down to the engines is fine as they may simply be able to deal with it directly, etc.. That's all good, and an interface for importing yuv to image data is already there, you can extend it to cover any premul ayuv format type with no problem. sure - and i would suggest we expand it to also import non-premul ARGB - thats basically all i was really suggesting. :) But, setting a color space, either globally or per obj, has only one real meaning - that the color space in question is going to be used as the current context for gfx ops. oooh no - for me it means that became the api with which u dealt with evas. evas internally would do whatever it damn well pleased. :) the only guarantee u had is that u could present data in format X and get it back in format X. what happend later was entirely out of scope and goign to happen in premul ARGB. Doing this for non premul anything, is shear folly. Any 'benefit' you claim can be obtained for apps/libs that want to deal with non-premul color spaces by deferring premultiplying till it may be needed and whatnot.. is microscopic compared to the confusion, complexity, etc. caused by this misrepresentation. Now, you can argue that maybe not setting, but rather importing, non-premul color space formats for conversion is ok.. But I don't see anything worthwhile in providing such interfaces for data and/or colors, and just see an increase in complexity in dealing with that internally and, again, microscopic gains. Let's assume that edje has been modified to pass premul colors/data to evas, and eet saves premul data, and that evas provides premul/non-premul conversion api functions for colors data.. Just where exactly in e17 would there be even minor pain caused by evas being premul only? every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) What about entrance, ewl/etk, etc? 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, Jul 04, 2006 at 12:11:10AM +0900, Carsten Haitzler wrote: On Sun, 2 Jul 2006 23:57:15 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: But, setting a color space, either globally or per obj, has only one real meaning - that the color space in question is going to be used as the current context for gfx ops. oooh no - for me it means that became the api with which u dealt with evas. evas internally would do whatever it damn well pleased. :) the only guarantee u had is that u could present data in format X and get it back in format X. what happend later was entirely out of scope and goign to happen in premul ARGB. With the added stipulation that the data returned may not be exactly the data given (due to colorspaces not mapping 1-1 on each other). Unless you plan on keeping the untouched data around somewhere (which would double the memory usage). 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, 4 Jul 2006 00:11:10 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) Etk doesn't often use evas_object_color_set() so it will be really easy to port. For .edc files, I really think the colors should remain non-premul RGBA colors since .edc files are made by graphic designers, and designers are used to non-premul RGBA colors (graphic tools give non-premul colors). And using premul colors will really make theming painful imho since themers often try different color settings to see which setting is the best looking. With premul colors, the themers would have to convert to premul colors each time they would like to change a color. Now, whether edje_cc should convert to premul on compilation or do it on runtime, I don't really know. Maybe it could be done during the compilation, so it'll save some work during runtime. Also, what do you think of having an API like that for image_data_set/get()? void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace); void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing); The colorspace param in the data_set() func describes the colorspace of the given data, and in data_get(), it describes the colorspace in which you'd like to get the data. The colorspace in which it's stored by Evas could depend on the engine (it could be colorspace if the engine is optimized for colorspace, or another more adapted colorspace). Perhaps that is what you were already discussing with Jose, I haven't understood very well. Regards, Simon TRENY MoOM 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Sun, Jul 02, 2006 at 12:35:34PM +0900, Carsten Haitzler wrote: what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). then we can begin a migration of code over to premul and remove the call - but still keep it there for the ability to switch into a more convenient colorspace. i am not sure this colorspace should affect image pixels though... that should be per image object as above. +1 Sounds good to me. rephorm 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
Carsten writes: 1. .. 5 ... The troubles of having evas' software engine do transforms in premul color space whereas the render engine does so in premul are only seen so far if you look carefully or try to do certain things.. But they are a very deep inconsistency and makes evas basically worthless for any serious consideration of these engines as more or less 'interchangeable'. 6. the problem we have is for evas_color_set() and then edje and nigh everything that depends on this. if we go premul for this just about everything will break and need fixing. this is a lot of stuff. Having edje pass premul colors to evas would be trivial. If that's all apps/libs are using then they wouldn't have to do a thing. what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). Sure. 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). What good would that do for all but the software engines (and possibly the gl engine). You can't make render do transforms with data in non premul colorspace - one'd just be back to the situation that exists now except with two sets of compositing (and other drawing) routines in the software engine. 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). What is the point of having a color space that you can't do gfx with internally except convert it to premul? Only if all the evas engines could work with both premul and non premul color space in their gfx handling routines would this make any sense.. and it would still be highly suspect to be able to use this coherently. 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). What's the point of having this in the canvas when such color spaces can't be used directly in a coherent way? You already have the YUV import call, and what does it do? Convert to rgb since there's no internal support by any of the engines to composite ayuv with argb. Not only that, but there are questions of coherence when it comes to using transforms that are not easily dealt -- just as now you have two different results from scaling data with the software vs the render engines when the results are rendered. Are you prepared to do scaling/shearing etc. in ayuv space prior to compositing - how will you have render do this right now? Have you thought out the results of what this will lead to vs first converting to rgb and then scaling/shearing..? Which one(s) you want and why? This is why I didn't want to add eg. an api func for adding ahsv colors to grads, and instead had the interpolation happen there.. I could imagine setting such an interpolation color space to be premul argb/ayuv, non premul argb/ayuv, etc. But there needs to be good reason.. and even more for having other color-space *entry* points. That colors can come in different color spaces alone is not good enough reason - conversion funcs are for that. then we can begin a migration of code over to premul and remove the call - but still keep it there for the ability to switch into a more convenient colorspace. i am not sure this colorspace should affect image pixels though... that should be per image object as above. It all sounds very nice... set the color space as you wish, per object even.. :) But it's not so nice when you look deeper. I would consider some of this to be partially viable only when the main engines you want to use (software and render) are capable of dealing with transforms and compositing in these color spaces.. Otherwise it's nothing but an inconsistent mess. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Sun, 2 Jul 2006 12:35:34 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). then we can begin a migration of code over to premul and remove the call - but still keep it there for the ability to switch into a more convenient colorspace. i am not sure this colorspace should affect image pixels though... that should be per image object as above. I don't really like the idea of having a couple of functions, evas_colorspace_set/get() to change the global colorspace of evas. In my opinion, it will confuse the things a bit more and will make the implementation harder. For example, if I start in the colorspace EVAS_COLORSPACE_ARGB_PREMUL, I set the colors of the objects, the data of the images, and then, I switch the colorspace EVAS_COLORSPACE_ARGB. What do I get when I'll try to get the colors or the data of the objects? Converted colors or the old premul colors? Another confusing situation with edje: if I render an edje object in the ARGB_PREMUL colorspace, will it look the same in the ARGB colorspace (i.e. will Edje directly evas_object_color_set() or will it convert the color?) Imho, the colorspace in which the data of an image is internally stored by Evas should depend on the engine used. For example, the software and the xrender engines should store it in premul colors, the OpenGL engine should store it in normal colors (since I don't think you can have a premul argb texture, but I'm probably wrong) and a XV engine (stupid idea...) should store it in YUV colors. That way, it will be stored the most efficient way in order to be rendered efficiently. There must be some scaling issues but I dont think that storing in an unique colorspace would solve it (since you'll have to do the conversion sooner or later, probably before the scaling transform if you want to benefit from the optimizations of the engine). So I think that an API like that could be good: void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace); void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing); So it's up to the user to choose the colorspace, (using ARGB_PREMUL to avoid a conversion with the 2 most common engines: software and xrender), and he can't be confused since it's he who makes the choice. Now, there is the problem of evas_object_color_set(). Imho, we have to choose, either we ask always for a premul color or always for a non-premul color, but I don't really like the idea of having a function evas_colorspace_set() to switch the current colorspace (and I don't like the idea of having a colorspace by object too). And if we'll have to choose, I'm still for non-premul colors!! :) Regards, :) Simon TRENY MoOm 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Sun, 2 Jul 2006 08:25:04 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Carsten writes: 1. .. 5 ... The troubles of having evas' software engine do transforms in premul color space whereas the render engine does so in premul are only seen so far if you look carefully or try to do certain things.. But they are a very deep inconsistency and makes evas basically worthless for any serious consideration of these engines as more or less 'interchangeable'. no - i was meaning allow at the evas API level to PROVIDE non-premul image data. evas converts to premul internally like the xrender engine does - keeping a private premul copy when needed. this is a convenience for programmers who can't/dont handle premul in their app. the conversion routines are internal - they are simply called when needed. 6. the problem we have is for evas_color_set() and then edje and nigh everything that depends on this. if we go premul for this just about everything will break and need fixing. this is a lot of stuff. Having edje pass premul colors to evas would be trivial. If that's all apps/libs are using then they wouldn't have to do a thing. sure- but it's not just edje - a lot of apps, widget sets etc. then again if everyone is willing to help port the workload can be reduced. what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). Sure. 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). What good would that do for all but the software engines (and possibly the gl engine). You can't make render do transforms with data in non premul colorspace - one'd just be back to the situation that exists now except with two sets of compositing (and other drawing) routines in the software engine. 1. convenience for programmers/compatibility and the ability to extend it in future to allwo DIRECT YUV access for example for emotion - and then the ENGINE has to deal with conversion, not evas. if the engine can deal with yuv directly - then it will do it natively (eg use xvideo or YUV gl textures etc.). right now this is a big problem as we can't make use of any acceleration of yuv-rgb. admittedly xvideo sucks right now as it basically will not (in almost all cases) be able to write/composite xvideo yuv data TO a pixmap - BUt this is set to change - as the word in from keithp etc. is - when drivers catch up etc. we should just be ready for the day it happens and then simply hook up the right routines, but until that day, do out own yuv-rgb conversion, but at the engine, not the evas level. 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). What is the point of having a color space that you can't do gfx with internally except convert it to premul? Only if all the evas engines could work with both premul and non premul color space in their gfx handling routines would this make any sense.. and it would still be highly suspect to be able to use this coherently. as an input format only. it gets converted when needed into the native format. you agreed providing routines to go to/from premul is good - if u are providing them- how are u going to USE them? i wasn't thinking of exposing them to apps at the evas api level - only as internal calls that convert the data presented to the app as the image pixel data. 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). What's the point of having this in the canvas when such color spaces can't be used directly in a coherent way? evas does the conversion to an internal native format as needed (premul argb). otherwise we will be moving that conversion outside of evas - that would be the big fat port to premul. You already have the YUV import call, and what does it do? Convert to rgb since there's no internal support by any of the engines to composite ayuv with argb. Not only that, but there are questions of coherence when it comes to using transforms that are not easily dealt -- just as now you have two different results from scaling data with the software vs the render engines when the results are rendered. Are you prepared to do scaling/shearing etc. in ayuv space prior to compositing
Re: [E-devel] Premultiply or not
we need the ability to have image objects in different colrospaces yugv(and its variants, yuv422, yuv420, etc. etc.) is a long-term must. the ENGINE has to deal with yuv data. if it can't it can always use the yuv import calls internally to RGBA then do it all in RGBA land - but if the subsyetm (gl/xrender/etc.) can do yuv natively - then do it that way, hoping the hw accel does a much better job than we do. adding in ARGB non-premul as another colorspace is merely convenience as its just the SAME logic as handling a yuv image object - having to convert to a native format before using it. in fact its probably the thing we would want to test with to start with. yuv would get support later. Let's agree on one thing: The gfx operations, unless otherwise explicitly stated, will be done in premul argb color space, or a linear equivalent of it.. Ok, fine.. and actually premul ayuv would be ok too since when decoded yuv is linearly related to rgb (hsv eg. is not). There's already such an interface to set imported data from yuv, and moving the 'conversion' to rgb down to the engines is fine as they may simply be able to deal with it directly, etc.. That's all good, and an interface for importing yuv to image data is already there, you can extend it to cover any premul ayuv format type with no problem. But, setting a color space, either globally or per obj, has only one real meaning - that the color space in question is going to be used as the current context for gfx ops. Doing this for non premul anything, is shear folly. Any 'benefit' you claim can be obtained for apps/libs that want to deal with non-premul color spaces by deferring premultiplying till it may be needed and whatnot.. is microscopic compared to the confusion, complexity, etc. caused by this misrepresentation. Now, you can argue that maybe not setting, but rather importing, non-premul color space formats for conversion is ok.. But I don't see anything worthwhile in providing such interfaces for data and/or colors, and just see an increase in complexity in dealing with that internally and, again, microscopic gains. Let's assume that edje has been modified to pass premul colors/data to evas, and eet saves premul data, and that evas provides premul/non-premul conversion api functions for colors data.. Just where exactly in e17 would there be even minor pain caused by evas being premul only? What about entrance, ewl/etk, etc? 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Thu, 29 Jun 2006 08:24:48 -0500 [EMAIL PROTECTED] babbled: Ok - time to jump in on this thread. 1. premultiply does speed things up in the internal engine. it also would speed up dealing with xrender as we then deal in xrender's native ARGB colorspace. premul makes sens from many viewpoints. 2. yes - it WORKS differently to non premul space. it literally is a different colorspace with alpha and a transition from 1 colors that vary alpha in premul does NOT work (always) the same as non-premul. thats how it works. a lot of points within a linear traversal in premul and non-premul space can be linear, but others can't. as simon pointed out - that is a case where the linear path in premul does not match non-premul. this is something i think we can live with. 3. premul solves some of our existing up and downscaling problems where we interpolate the COLOR to whatever rgb is off in the blank pixel next to a solid pixel. you will notice sometimes blackish halos or sometimes colored ones. it depends on the source pixels loaded. often you don't notice - but it's something i have noticed and this fixes it with no performance impact (and actually speedups). 4. xrender works in premul. right now when copying evas pixel data to xrender we need to do a premul process. its not very optimised, but it works and goign to premul internally will allow us to save this step IF the source image fromat is premultiplied (i will add eet code to do this actually as then edje files with image data can have all the data already pre-processed). 5. changing the pixel format to premul wont impact a lot - only things that directly access image ARGB pixels via get/set data will be affected, and then only if they use the alpha channel. 6. the problem we have is for evas_color_set() and then edje and nigh everything that depends on this. if we go premul for this just about everything will break and need fixing. this is a lot of stuff. what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). then we can begin a migration of code over to premul and remove the call - but still keep it there for the ability to switch into a more convenient colorspace. i am not sure this colorspace should affect image pixels though... that should be per image object as above. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
Brian and Nathan write:
I think we should at least provide a set of functions for
converting image data / color values between the two spaces.
...
I would also suggest a set of conversion functions for performing
the premul conversion on non-premul image data. ...
...
Sure, without question :)
Let me warn everyone who still intends to work using
non-premul data (and/or colors) -- it's tricky to mix these
two color spaces, you may end up getting mixed-up yourself.
Here's an example of what happens right now in evas
because we're using non-premul data in the software based
engines vs what happens when we use the xrender engine.
Take the following Simon inspired example:
Evas_Object *obj;
unsigned int data[2] = {0xff00ff00, 0x00ff};
// This gives 2x1 sized image data with opaque-green
// and transparent-red pixels.
obj = evas_object_image_add(some_evas);
evas_object_image_size_set(obj, 2, 1);
evas_object_image_data_set(obj, (unsigned int *)data);
evas_object_iamge_alpha_set(obj, 1);
evas_object_resize(obj, 100, 100);
evas_object_image_fill_set(obj, 0, 0, 100, 100);
evas_object_image_smooth_scale_set(obj, 1);
evas_object_image_border_set(obj, 0, 0, 0, 0);
evas_object_move(obj, some_x, some_y);
evas_object_layer_set(obj, some_layer);
evas_object_clip_set(obj, some_clip);
evas_object_show(obj);
If you display this with the software-x11 engine
(onto a white background say), you will see a 100x100 image
which varies from opaque-green at the left edje to transparent
at the right edje, with some redish and brownish in between.
However, if you display this with the xrender-x11 engine,
you will see an image varying from opaque-green at the left edje
to transparent at the right edje with no 'redish' or 'brownish'
anywhere.
I haven't actually checked it with what's in CVS (we've been
making scaling changes lately), but I think that's what will happen.
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
Jose writes:
Let me warn everyone who still intends to work using
non-premul data (and/or colors) -- it's tricky to mix these
two color spaces, you may end up getting mixed-up yourself.
Here's an example of what happens right now in evas
because we're using non-premul data in the software based
engines vs what happens when we use the xrender engine.
Take the following Simon inspired example:
Evas_Object *obj;
unsigned int data[2] = {0xff00ff00, 0x00ff};
// This gives 2x1 sized image data with opaque-green
// and transparent-red pixels.
obj = evas_object_image_add(some_evas);
evas_object_image_size_set(obj, 2, 1);
evas_object_image_data_set(obj, (unsigned int *)data);
evas_object_iamge_alpha_set(obj, 1);
evas_object_resize(obj, 100, 100);
evas_object_image_fill_set(obj, 0, 0, 100, 100);
evas_object_image_smooth_scale_set(obj, 1);
evas_object_image_border_set(obj, 0, 0, 0, 0);
evas_object_move(obj, some_x, some_y);
evas_object_layer_set(obj, some_layer);
evas_object_clip_set(obj, some_clip);
evas_object_show(obj);
If you display this with the software-x11 engine
(onto a white background say), you will see a 100x100 image
which varies from opaque-green at the left edje to transparent
at the right edje, with some redish and brownish in between.
However, if you display this with the xrender-x11 engine,
you will see an image varying from opaque-green at the left edje
to transparent at the right edje with no 'redish' or 'brownish'
anywhere.
This is the sort of example that really helps make the case for pre-mul
everywhere. As in this case, the 'image' LOOKS like its half green and
half nothing. So, I would think most would be surprised if there were
reddish/brownish appearing with smooth scaling.
Thanks again.
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
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). Yes, that's a good way to put it I think. Also, one should note that the concept of alpha is not always really best seen as equivalent to opacity -- this is really a good interpretation for ops that are 'additive' in nature.. In general, alpha is really more like an intensity or brightness of some kind, and modulates the rgb color components. 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. Yes. Actually aa text gives a basic example of a non-trivial shape which we have to color or texture in order to display it. We obtain the glyphs as alpha-masks, ie. arrays of alpha data only, no rgb color data, and then we have to decide what it means to render this to some dst image with some argb texture data (usually just a single color). If we were to multiply the argb texture data with the glyph alpha mask, then we obtain a new argb texture 'fitted' to the glyph shape which we can then use for as our src image rendering... However, this only really works well for 'additive' kinds of rendering ops. In general, we actually use the glyph alpha mask as a linear interpolator between the dst image and the result of op(src-texture, dst). This is kind of a pain to do with the xrender engine for some ops with external masks, as it likes to intertwine the mask and src pictures... but it can be done. It's not in the evas xrender engine yet, pending the move to premul and a restructuring of the image drawing pipeline. 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. That's a possibility.. there may be other ways too. I just don't want to have here it's this.. but you can do something else there, because who knows why this one is special but not that one.. I would prefer that evas not modify its api color inputs, so that what-you-give-is-what-is-used (more or less), and consistent in its use of color data. Keith Packard had an interesting idea for a mechanism that would allow one to obtain this with premul inputs and not have to go thru the work of generating extra premul grad stops to obtain such results.. namely, we add to grads the ability to specify alpha- only stops as well as premul argb color stops. We can do this easily in evas, with software only if need be (and that's how we're doing grads
Re: [E-devel] Premultiply or not
On Tue, Jun 27, 2006 at 08:11:18AM +, [EMAIL PROTECTED] wrote: 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 How about 2.5, with the extra addition of a simpler mechanism for obtaining non-premul grads kinds of results as suggested above (although you could do this by generating the spectrum yourself in non-premul space, premul the result and pass it to the grad api via the grad 'data_set' api func). One is then free to have libs which decide to have interfaces with premul, or non-premul, or a combination, as they see fit... and evas will be able to support them. jose. I think we should at least provide a set of functions for converting image data / color values between the two spaces. (Sure, its simple op, but its just nicer imo to have one function call abstracting it away). So, if people want/need non-premul image data they could just do something like DATA32 *data = evas_object_image_demultiply(evas_object_image_data_get(o)); and conversely something like: evas_object_image_data_set(o, evas_image_data_premultiply(data)); for setting data. Essentially this is what evas would have to do anyway if we kept the API non-premul. This way its (almost) as convenient, while explicitly making the programmer aware of the color space transformation. -- 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
demultiplying is not always possible... (how do you de-multiply a colour that has alpha of 0?) A On Tue, 2006-06-27 at 08:56 -0500, [EMAIL PROTECTED] wrote: On Tue, Jun 27, 2006 at 08:11:18AM +, [EMAIL PROTECTED] wrote: 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 How about 2.5, with the extra addition of a simpler mechanism for obtaining non-premul grads kinds of results as suggested above (although you could do this by generating the spectrum yourself in non-premul space, premul the result and pass it to the grad api via the grad 'data_set' api func). One is then free to have libs which decide to have interfaces with premul, or non-premul, or a combination, as they see fit... and evas will be able to support them. jose. I think we should at least provide a set of functions for converting image data / color values between the two spaces. (Sure, its simple op, but its just nicer imo to have one function call abstracting it away). So, if people want/need non-premul image data they could just do something like DATA32 *data = evas_object_image_demultiply(evas_object_image_data_get(o)); and conversely something like: evas_object_image_data_set(o, evas_image_data_premultiply(data)); for setting data. Essentially this is what evas would have to do anyway if we kept the API non-premul. This way its (almost) as convenient, while explicitly making the programmer aware of the color space transformation. -- 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, Jun 27, 2006 at 03:15:28PM +0100, Andrew Williams wrote: demultiplying is not always possible... (how do you de-multiply a colour that has alpha of 0?) A You just have to pick an (arbitrary) color to set it to. E.g. black. Its not 1-1 but its consistant. (Similar to how in HSV, if S=0, H is arbitrary).-- 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On 6/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: How about 2.5, with the extra addition of a simpler mechanism for obtaining non-premul grads kinds of results as suggested above (although you could do this by generating the spectrum yourself in non-premul space, premul the result and pass it to the grad api via the grad 'data_set' api func). One is then free to have libs which decide to have interfaces with premul, or non-premul, or a combination, as they see fit... and evas will be able to support them. I would also suggest a set of conversion functions for performing the premul conversion on non-premul image data. Something similar to what is done for YUV conversion. Then we can provide some SIMD accelerated versions, and simpilfy the API for the end user. With these additions, I think the premul change becomes much more reasonable. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Premultiply or not
My thanks to Simon for forwarding some emails while I am spam, and thanks to everyone for the feedback on this premul color deal :) I've gone over this a bit, and I'd like to recap here what I think about all this. It's definitely a 'plus' for evas to move with working in premul color space internally (and recall: a,r,g,b is premul iff a = r,g,b). There are many reasons for this.. some I've already stated here [and BTW: this was all raster's idea to begin with - please send many nasty emails to him]. If we accept this and move that way, then the question becomes: How would this affect apps/libs using evas, and what do we do about it? Any function that gets/sets color data will be affected, one way or another... some in 'minor' ways, some in 'big' ways - both performance wise and semantic wise. Since most here are used to working with non-premul colors, and thus most 'legacy' stuff assumes that.. it will seem like a terrible idea to move to working with premul colors, and would prefer that evas would this all internally and keep everything the same otherwise. This however leads to problems since as mentioned above the internal use of premul colors affects things one way or another. The get/set functions that deal with image data would have to constantly transform from premul to non-premul thus making the use of these very slow.. also, if you want to work with the data doing graphics ops yourself, then you would be better off doing so with it in premul color space, as it's easier and faster there. 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. 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. 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 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. 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.
Re: [E-devel] Premultiply or not
On Mon, 26 Jun 2006 06:37:21 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It's definitely a 'plus' for evas to move with working in premul color space internally (and recall: a,r,g,b is premul iff a = r,g,b). There are many reasons for this.. some I've already stated here Just to clarify things, is it a case of most of the pixel twiddling needs to have this multiplication step done anyway, so we might as well pre-multiply at the beginning to avoid lots of lengthy multiplications happening deep in pixel handling loops, and some external sources of pixels already come in premul form anyway? signature.asc Description: PGP signature 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Mon, 26 Jun 2006 06:37:21 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : The get/set functions that deal with image data would have to constantly transform from premul to non-premul thus making the use of these very slow.. also, if you want to work with the data doing graphics ops yourself, then you would be better off doing so with it in premul color space, as it's easier and faster there. 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. Yeah, I agree image_data_set/get() could gain from using premul alpha colors. And since image_data_set/get() is not used really often, or mainly with alpha=255, it won't break a lot of things. 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 grads, I would have thought that using premul colors was actually more restrictive than using non-premul colors, mostly because the conversion from non-premul to premul colors is not reversible (i.e if alpha=0, you can't get back the original non-premul color from the converted premul color). So, how can you make a linear grad from opaque red to transparent green with premul colors? With non premul colors, you just have to add 2 colors to the grad: 255 0 0 255 for opaque red and 0 255 0 0 for transparent green. In premul colors, there is no transparent green (well... I agree, transparent green is visually the same color than transparent red, since it's all transparent...) 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. I'd rather be for solution 2, i.e. keep all the API functions use non-premul colors, except image_data_set/get(). Simon TRENY MoOm 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
It's definitely a 'plus' for evas to move with working in premul color space internally (and recall: a,r,g,b is premul iff a = r,g,b). There are many reasons for this.. some I've already stated here Just to clarify things, is it a case of most of the pixel twiddling needs to have this multiplication step done anyway, so we might as well pre-multiply at the beginning to avoid lots of lengthy multiplications happening deep in pixel handling loops, and some external sources of pixels already come in premul form anyway? Most of the compositing ops multiply the alpha by the r,g,b if one can't assume that a = r,g,b. And if you are dealing with a dst image which itself has alpha, then not only do you have to mult the src colors by the alpha (agian, if they are not premul), but you also should *divide* the result of blending the colors by the result alpha - *extremely* slow.. which evas and imlib2 got around by using a 65Kb table that is somewhat faster than dividing, but which does not generalize well to other ops. But even when no ops are done, if the image has alpha, then one should replace the r,g,b by their alpha multiplied versions for sending to the display - definitely needed with the xrender engine for setting data on pictures. Internally, it's *much* more efficient to use premul colors, for dealing with compositing ops and for dealing with the xrender engine. If evas works internally with premul data, then when you set an object's color to (r,g,b,a), if we have evas assume that this is *not* premul, then evas will have no choice but to replace this by (r*a/255,g*a/255,b*a/255,a). That's what it *will* use to color the object by - not the input (r,g,b,a). The problem becomes somewhat coplicated when one has the option of 'doing stuff' with the colors other than just using them as a simple multiplier (which is what setting an obj's color will do). Then, lots of ambiguities and limitations come up with non-premul color inputs. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
Just to clarify things, is it a case of most of the pixel twiddling needs to have this multiplication step done anyway, so we might as well pre-multiply at the beginning to avoid lots of lengthy multiplications happening deep in pixel handling loops, and some external sources of pixels already come in premul form anyway? I'm curious about this as well. If I understand correctly, premul image data is only handy for when you actually start compositing alpha-based pixel data? Most single-image operations just use simple pixel-by-pixel or image-kernel-based operations, with or without alpha. The alpha only starts to 'mean' something when you actually perform the compositing with other image data. In that case I fail to see why it would be handy to have premul data in the stage where compositing isn't done yet. And for the same reason I fail to see why it would be necessary for external sources to hand premul data to Evas (except for performance of course). Because: you're eventually going to composite things unless you're writing a lib that only does convolutions on single images, which evas is not. So, evas will need to do the premultiplying each time it wants to composite stuff, or hand data to render -- you won't have to do this if the input data is already premul. Further, the non- premul compositing algorithms are klunky, slow, and inaccurate when there's a dst image with alpha. I also find it counter-intuitive to do a set_color with a premul color. I kind of see this as your user interface to your library. I've yet to see one photoshop/gimp/inkscape-or-clone which has you manipulate colors in premul, even though it handles them like that internally. But of course, Evas is not a painting program, so why shouldn't premul be handled Some programs come from an era where 'alpha' was a new concept - some didn't even do alpha-blending or anti-aliasing for quite some time. Others try to conform to certain specs which have their issues, and others have a lot of legacy stuff that they are bound to, no matter how screwed up that makes things. Others still may be catering to the idea that using premul colors will confuse people, since everyone is so used to non-premul ones... The real confusion comes from having to switch from one color space to another. As a counterpoint, Cairo for example (IIRC), takes only non-premul colors in for setting colors and gradient stops, and does all the premul stuff in the engine itself, after which it spits out premul images, for easy composting. You can de-premul those at will afterwards. That system works too, and it is pretty intuitive. However it is kind of a shock when you first discover that you pump non-premul in and it spits premul out. Cairo does this mostly to directly support the SVG spec (which has that).. You can see a recent thread in the cairo list where I brought this up there if you're interested. What I do find very very interesting, is the fact that premul colors allow you to 'glow' a color by pushing the color value over the alpha value (if you violate the a = r,g,b property). That is something that IS very handy and I can't think of any easy way to accomplish this with non-premul data. So I do believe that using premul gives you more possibilities as well. There are many ways that it gives more flexibility -- using non-premul colors is actually a restriction in many ways. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
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 grads, I would have thought that using premul colors was actually more restrictive than using non-premul colors, mostly because the conversion from non-premul to premul colors is not reversible (i.e if alpha=0, you can't get back the original non-premul color from the converted premul color). So, how can you make a linear grad from opaque red to transparent green with premul colors? With non premul colors, you just have to add 2 colors to the grad: 255 0 0 255 for opaque red and 0 255 0 0 for transparent green. In premul colors, there is no transparent green (well... I agree, transparent green is visually the same color than transparent red, since it's all transparent...) It seems this way mainly because everyone is so used to using non-premul colors (due to legacy stuff and whatnot). This is somewhat subtle, but in short no you can't make a gradient from opaque-red to transp-green with premul colors using just *two* colors. You can do it (arbitrarily close) by using more premul colors, but not just two. It's the same thing as the 'transition' case you brought up. The use of non-premul colors for this is mostly just a convenience to obtain said results easily. But it has a heavy price: It creates all sorts of confusion and it makes it impossible to do real linear gradient spectrums with premul colors. As I mentioned in a previous later, I went into this very issue on the cairo list recently.. you can check that thread out if you're interested in this a bit. 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. I'd rather be for solution 2, i.e. keep all the API functions use non-premul colors, except image_data_set/get(). Simon TRENY MoOm That's raster's favorite as well, and it was mine too until very recently... until I started looking into this in more detail. Not anymore for me. I just sense this to be a bad idea whose only merit is to bring future problems just to cause less pain for current stuff. This is a recurring issue that seems to feed on itself :( 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Mon, Jun 26, 2006 at 06:37:21AM +, [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
