April 05, 2008
The Dirty Secrets of Premultiplied Alpha

Okay, I'm exaggerating. Several years after BitmapData was introduced to the Flash player it's not really a secret anymore that Flash uses a feature called premultiplied alpha when it stores transparent pixels. But it is a bit dirty after all. In case you want to skip the following nerd talk you can check out the demo right away - but don't cry if you don't understand what it is telling you.

"Premultiplied" alpha means that the alpha information of a pixel is not only stored in the alpha channel itself, but it is already "multiplied" into the red, green and blue channel. In Flash practice this means that if you have a nice orange #fff8000 and reduce the alpha to 50% it will be stored as #80803f00. This means that each value of the color channels will never be bigger than that of the alpha channel.

The reason to do this is performance. The image processing algorithm to composite two bitmaps always requires that the alpha channels are being multplied into the color information, so if you have a tool that needs to do a lot of compositing it simply saves you a good amount of time if you don't have to do these multiplications for every pixel. And as we know Flash is all about compositing things (whenever you overlap two antialiased lines some serious composting takes place) and Flash is pretty fast with this.

But there is a problem. Pixels are stored as 32 bit integer values, this means each channel has a range of 8 bit or 256 possible values. On the other hand calculations with pixels usually are done in floating point mathematics which means that the range of possible in-between values can be much higher. As long as you stay within floating point that's cool, but unfortunatly at some point you have to write those values back into a bitmap which means that if you have a result of 43.7 it will be rounded to 44 or even worse to 43.

Normally these little errors do not cause much trouble. But once you start dealing with small alpha values the error accumulates. An example: when you set the alpha value of a pixel to 16 all color values will be multiplied with a factor of 16/256 = 0.0625. So a gray pixel of 128 will become 128 * 0.0625 = 8, a darker pixel of 64 will become 64 * 0.0625 = 4. But a slightly lighter pixel of maybe 67 will become 67 * 0.0625 = 4.1875 - yet there are no decimals in integer pixels which means it will also become 4. The effect that you will get posterization - setting your alpha channel to 8 means that you also reduce your color channels to 8 levels, this means instead = 256*256*256 different colors you will end up with a maximum of 8*8*8 = 512 different colors.

Well, as long as you keep your alpha at 8 you will not notice any difference but once you increase the alpha the desaster becomes obvious. Getting back from alpha 8 to alpha 255 means multiplying each channel by 16. This means that our old 64 pixel which was reduced to 4 becomes 4*16 = 64. Now that's great - same value as before! But the 67 pixel had also been reduced to 4 which means 4*16 = 64 - that's 3 smaller than 67. This means this information is lost forever and cannot be restored. And the eye can be quite unforgiving when it comes to certain subtle shades.

In order to show you the extend of this effect I've built a demo that visualizes the amount of information loss that happens: It first reduces an image's alpha channel to a chosen value and then sets the alpha back to 255. What you will see is that for small alpha values there is some nasty posterization happening. But even if you just reduce the alpha to 254 the image will suffer information loss, you can see that by switching on the "show data loss" checkbox. What this does is to take a difference between the original and the restored image. Since the loss can be small there is an automatic multiplication involved to increase the contrast.

So what can you do when you have to preserve the image information? Well, you have to take the slow road and always keep the alpha channel separate from the image. This means that you maintain three bitmaps - one is used to store the RGB information, one stores the alpha channel and the third one is used to be displayed on screen by joining both of them together.

Posted at April 05, 2008 04:45 PM | Further reading
Comments

Interesting article, I learned something new.
thanks! :)

Posted by: kris on April 6, 2008 01:46 PM

This only happens when you "commit" the alpha channel, for example when you draw the bitmap into a destination, right? If have a BitmapData that has this pixel stored in it: RGBA(255, 255, 255, 0); and I do a getPixel I'm not going to get back RGBA(0, 0, 0, 0); (pre-multiplied alpha value), am I?

In the end, though, pre-multiple alpha is the *right* way to go, it just solves way more problems than it creates. Go and read all the discussions from the CGI world (and the 3D games world) where this debate has popped up before. In the end, pre-multiplied alpha just works more intuitively for our artists and our pipelines.

Posted by: Troy Gilbert on April 8, 2008 06:22 PM

Troy, unfortunately it is exactly like this. In Flash you cannot store a white pixel that is entirely transparent:

var map:BitmapData = new BitmapData(1,1,true,0xffffffff);

map.setPixel32(0,0,0x00ffffff); // RGBA(255, 255, 255, 0);
trace( map.getPixel32(0,0).toString(16)) // traces 0x00000000

map.setPixel32(0,0,0x20fcfcfc);
trace( map.getPixel32(0,0).toString(16)) // traces 0x20ffffff

Posted by: Mario Klingemann on April 8, 2008 08:04 PM
Post a comment
Name:


Email Address:


URL:


Comments:


Remember info?



Thank you!

Most Visited Entries
Sketches, Works & Source Code
Lectures
Contact
Backlog
In Love with
Powered by
Movable Type 2.661

© Copyright Mario Klingemann

Syndicate this site:
RSS 1.0 - RSS 2.0

Quasimondo @ flickr
Quasimondo @ LinkedIn
Quasimondo @ Twitter
Quasimondo @ Facebook
Quasimondo @ MySpace
Quasimondo is a Bright
Citizen of the TRansnational Republic
My other blog in german
Impressum


My family name is written Klingemann,
not Klingelmann, Klingeman, Klingaman, Kingemann,
Kindermann, Killingaman, Klingman, Klingmann, Klingonman
Klingemman, Cleangerman, Klingerman or Kleangerman

profile for Quasimondo at Stack Overflow, Q&A for professional and enthusiast programmers