From: <jos...@ju...> - 2006-07-04 00:51:23
|
> > 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. |
From: <jos...@ju...> - 2006-07-04 04:19:46
|
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. |
From: Carsten H. (T. R. <ra...@ra...> - 2006-09-06 12:14:07
|
On Tue, 4 Jul 2006 04:18:18 GMT "jos...@ju..." <jos...@ju...> 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) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: <jos...@ju...> - 2006-09-07 10:40:38
|
> > 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. 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? |
From: Carsten H. (T. R. <ra...@ra...> - 2006-09-16 05:58:31
|
On Thu, 7 Sep 2006 10:38:20 GMT "jos...@ju..." <jos...@ju...> 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=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |