Hi Bob, Thank you for your reply ! I agree with you regarding the fact that PNG and others are not using premultiplied alpha and I think it is a very good thing. Using this "runtime" format to store data is a bad idea as you loose color accuracy (if not using floating color channels). However, when the need is a fast graphic composition for screen rendering, premultiplied alpha saves a lot of time/cpu ! It makes composition runs ~ twice faster, whatever your CPU or GPU is.
Regarding "a particular meaning for Alpha", I disagree, for 2 reasons : A premultiplied color would be useless for an inverted Alpha : for inverted alpha, (where 0 is opaque), all RGB value would be 0 because premultiplied format is RGB' = a * RGB. So premultiplied alpha exists only for the convention 0 (transparent) to 1 (opaque). A second reason is that many hardware and software composition engine are expecting this "de facto" normalized premultiplied alpha. OpenGL, Apple iOs API, Qt QPaintEngine and others are using this format. In my software, I use such images to compose hundreds of layers before a final blit to screen. Getting some help from hardware is not a bad thing to get comfortable FPS. Obviously, my goal is to avoid to do several format switches for each graphic pipeline stage. I guess that you don't have this problem with GraphicsMagick (that I like BTW and uses in my scripts) as don't have to rely on external tools/libs/hardware. As PreMultiplied Alpha can be seen as a standard, I think it deserves some attention ;-) even if supporting it, is not useful for anyone... Seb Le 11/12/2012 16:22, Bob Friesenhahn a écrit : > On Tue, 11 Dec 2012, Sebastien Leon wrote: > >> >> In my graphic pipeline, it appears that the image that I would like to >> process are in premultiplied RGBA, which is much faster to blend that >> regular RGBA. >> LittleCMS, for now, left unchanged the alpha channel and does not care >> about it. >> Obviously, any premultiplied R/G/B (or any other kind of channel) will >> not be handled correctly if there is no specific code in LittleCMS core. >> >> As a turn-around, it is always possible to turn the premultiplied >> feature off or to convert to regular RGBA before/after the call to >> cmsDoTransform. But the performances are damn impacted. >> The other point to consider is the potential benefit to take care of >> Alpha : if (alpha == 0), there is no need to process this pixel, as the >> point is fully transparent. (btw, this optimization could already be >> enable for regular RGBA) > > I don't see how lcms could possibly properly deal with premultiplied > alpha. In this case, the color channels are (permanently) influenced > by a non-color channel, and the final result is usually based on a > composition on some other image/color (default black). > > It would be wrong to assume a particular meaning for Alpha beyond its > definition in some particular file format (e.g. TIFF). > > The software I maintain uses inverted alpha internally so zero is > fully opaque. > > IMHO premultiplied alpha is an interesting idea (codified in the TIFF > file format) which ultimately causes more harm than benefits. It was > proposed in a time when CPUs were vastly less powerful than today. > Note that the PNG file format (which makes more use of alpha than > perhaps any other format) does not use premultiplied alpha. > > Bob ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
