From Wikipedia:
"Alpha compositing is the process of combining an image with a background to create the appearance of partial transparency. It is often useful to render image elements in separate passes, and then combine the resulting multiple 2D images into a single, final image in a process called compositing."
I am making a Pong game. I start by clearing my background to CornflowerBlue (100, 149, 237). I then draw a translucent grey box (128, 128, 128, 128) at the top of the screen, which will form the background of my score display. With conventional alpha blending:
((128, 128, 128) * 0.5) + ((100, 149, 237) * (1 - 0.5)) = (114, 138, 182)
Well and good. But over time, my overlays get more complex, including a map, radar, waypoint indicators, mission objectives, leaderboard rankings, etc. (what can I say, this is a complex Pong game :-) To avoid redrawing so much stuff every frame, wouldn't it be cool if I could draw the overlays just once to a rendertarget, then copy the resulting static image over the top of my animating gameplay?
Unfortunately, this doesn't work using conventional alpha blending:
Clear rendertarget to (0, 0, 0, 0)
Blend 50% grey into the rendertarget:
((128, 128, 128, 128) * 0.5) + ((0, 0, 0, 0) * (1 - 0.5)) = (64, 64, 64, 64)
Clear backbuffer to CornflowerBlue (100, 149, 237)
Blend rendertarget over the backbuffer:
((64, 64, 64) * 0.25) + ((100, 149, 237) * (1 - 0.25)) = (91, 127, 194)
Whoah! That's not even remotely the same result as before. The blend operation is happening twice: first when we draw into the rendertarget, then again when we draw the rendertarget into the backbuffer. Our alpha value ends up getting squared, so 0.5 becomes 0.25.
We could fix this by removing one of the blend operations:
But these are rarely good solutions, since you most likely need blending in both places (the overlays in my Pong game are built from many layers of alpha blended graphics, and the gameplay scene should be visible behind them).
Given a series of drawing operations which blend over the top of each other:
result = a -> b -> c -> d
we would like to be able to group a set of calls from the middle of this sequence, storing their result in a rendertarget, then later replace that set of calls with the contents of the rendertarget:
tmp = b -> c
result = a -> tmp -> d
The problem is that this changes the order of the blend operations. What was:
result = blend(blend(blend(a, b), c), d)
becomes:
result = blend(blend(a, blend(b, c)), d)
Because conventional alpha blending is not associative, changing the order of evaluation changes the result.
Premultiplied alpha blending is associative, so any number of blending operations can be grouped and reordered without affecting the final result.
To use premultiplied alpha, we make two changes:
Working through the same example as before:
Clear rendertarget to (0, 0, 0, 0)
Blend 50% grey into the rendertarget:
(64, 64, 64, 128) + ((0, 0, 0, 0) * (1 - 0.5)) = (64, 64, 64, 128)
Clear backbuffer to CornflowerBlue (100, 149, 237)
Blend rendertarget over the backbuffer:
(64, 64, 64) + ((100, 149, 237) * (1 - 0.5)) = (114, 138, 182)
Tada! That's the same result as when we were drawing everything directly to the backbuffer.
Premultiplied alpha r0x0rz.
Alvy Ray Smith writes about the invention of the alpha channel and image composition. I find it interesting that this was invented in the 1970s, and fully grokked as of the classic Porter-Duff paper in 1984, yet here we are a quarter of a century later, still having a hard time making composition work right because for some reason premultiplied alpha never became as widely understood as it deserves to be.