User:Lkesteloot/premultiplied alpha

Premultiplied alpha (or alpha premultiplication) is a method for storing semi-transparent colors in images in order to speed up subsequent alpha compositing during digital compositing. Note that the name implies that the alpha channel is premultipled, but this is misleading. It's the color channels that are premultiplied by the alpha channel.

Colors in RGBA images can be stored normally or premultiplied by the alpha channel. For example, a pixel that's full red (1,0,0) and has a 50% alpha (0.5), can be stored with premultiplied colors (0.5,0,0,0.5) or with non-premultiplied colors (1,0,0,0.5).

There are advantages to both schemes. For example, with non-premultiplied colors, the opacity of an image can be changed simply by tweaking its alpha channel. Or color correction, say remapping bright red to some other color, can be done without concern that the alpha channel has made bright red numerically like dark red simply because of transparency.

But with premultiplied colors, the math of compositing images together is simpler and a division can be avoided much of the time.

The key to understanding the distinction is to give up the idea of alpha as transparent colored glass and instead see it as a screen mesh. For example, if alpha is 50%, then imagine a pixel, half of which is covered by the pixel's color and the other half is completely transparent. Specifically, imagine the left half covered and the right half transparent:

The question is whether the RGB values of the pixel should represent the color of the left half, or only the left half's contribution to the whole pixel. The advantages of doing the former (non-premultiplied) were outlined above. To see the advantages of premultiplied colors, consider compositing another pixel on top of our half-red one. The new one is white (1,1,1) and 50% transparent. So since we're using premultiplied colors, our RGBA is (0.5,0.5,0.5,0.5).

Assuming a screendoor transparency model, we don't know where this half pixel is compared to the half pixel we're compositing over. If our new pixel is also on the left side, then we'll cover the underlying pixel altogether. If it's on the right, we'll patch the hole perfectly. Since we don't know, we'll go half-way and turn it 90 degrees, with the bottom half of the pixel opaque white and the top half transparent:

The result is a pixel whose bottom half is white, top-left quarter is red, and top-right quarter is transparent:

The math for this operation is easy when the numbers are premultiplied:

<math>R' = R_F + (1 - A_F)R_B<math>

<math>G' = G_F + (1 - A_F)G_B<math>

<math>B' = B_F + (1 - A_F)B_B<math>

<math>A' = A_F + (1 - A_F)A_B<math>

The result is (0.75,0.5,0.5,0.75), which is the result of having each color's contribution to the pixel weighted by its area.

The math for non-premultiplied colors is more complex:

<math>R' = (R_FA_F + (1 - A_F)R_BA_B) / A'<math>

<math>G' = (G_FA_F + (1 - A_F)G_BA_B) / A'<math>

<math>B' = (B_FA_F + (1 - A_F)B_BA_B) / A'<math>

<math>A' = A_F + (1 - A_F)A_B<math>

The divide is unnecessary if the foreground or the background is opaque, which is a common situation since compositing sequences usually start with a fully-opaque background image and add things to it.

With 8-bit colors, premultiplying might result in losing color precision that will be needed later when dividing out the alpha to do some color correction.

Generally speaking, premultiplication is a better choice when compositing speed is important and other operations are less common, and non-premultiplication is better if compositing speed is not as important as precision and other operations.