> > 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=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
