Alpha Matting and Premultiplication
What is it and why should you care?
By Rui del-Negro
What is alpha matting?
Anyone vaguely familiar with digital image editing is likely to know what an "alpha channel" is. Although the term can be used to describe any bitmap channel other than the standard color ones (R, G and B, or C, M, Y and K), it usually refers to the opacity channel. I used the term opacity and not transparency because, typically, the higher the value of an alpha channel sample, the more opaque that pixel is (some file formats work the other way around, though, so calling it the transparency channel is fine). The alpha channel is typically represented by the letter A (ex., "RGBA").
But the term "alpha matting" is probably less familiar, and not very intuitive. In the context of digital image data formats, alpha matting does not refer to the use of alpha channels to create a "mask" or "matte"; it refers to a form of encoding where the value of the alpha channel influences the values of the color channels. This encoding method is also known as "premultiplied alpha" (although, as we'll see below, it's not always a simple multiplication).
Essentially, alpha matting mixes the color of each pixel with a predefined "background color" in a proportion defined by the alpha (opacity) channel. The more transparent the pixel, the higher the amount of the background color. If the pixel is 0% opaque (100% transparent), its color becomes identical to the background's.
There are three main types of alpha channel encoding: straight alpha (where the color and opacity values don't affect each other), black matte (where the color values are premultiplied by the opacity value, "mixing" them with black) and white matte (where the values are mixed with white, in a sort of "reverse premultiplication").
The following image illustrates the data that is actually stored in the RGB and A channels using each type of encoding. The alpha channel is represented as a grayscale image. White means opaque, black means transparent. The text is 100% opaque, the blue rectangle is 25% opaque, and the pixels in the antialiased edges have many different opacity levels:
|Figure 1 - Main alpha matte encoding formats|
As you can see, there is no difference in the alpha channel itself; the difference is only in the RGB channels.
The advantages of alpha matting are as follows:
1.If a program loads a bitmap with premultiplied alpha and sends only the RGB values to the screen (ignoring the alpha values), the image will look right.
2. Er... that's about it.
That's pretty much the only situation in which alpha premultiplication has any advantage: some vague compatibility with software that ignores the alpha channel. Which, as you can imagine, isn't really a common problem with modern compositing software. Instead, alpha matting creates all sorts of compatibility problems and quality issues. I'll start with the latter.
Let's say we have two pixels, whose 8-bit RGB values are [ 255 , 128 , 10 ] and [ 253 , 129 , 14 ], respectively. In our paint (or photo editing) program, we give them an opacity value of 25 (corresponding to 10% opacity, on an 8-bit scale, that goes from 0 to 255). If our program works with premultiplied alpha, the actual RGBA values saved will be [ 25 , 13 , 1 , 25 ] for the first pixel and [ 25 , 13 , 1, 25 ] for the second pixel. Noticed anything? Two pixels that started out with slightly different colors are now exactly identical. We have just lost the ability to distinguish between them based on color (ex., with a "magic wand" tool). If we later decide to increase the opacity of these pixels back to 100% (255), our software will change both to [ 250 , 130 , 10 , 255 ]. Noticed anything else? The RGB values don't actually match either of the original pixels (and are still identical to each other, of course).
Let's see what would have happened if we had used "straight" alpha, with no premultiplication or matting. The original pixel RGB values are [ 255 , 128 , 10 ] and [ 253 , 129 , 14 ], respectively. When we add the alpha channel, they are stored (to memory, or to a file on the disk) as [ 255 , 128 , 10 , 25 ] and [ 253 , 129 , 14 , 25 ]. Still perfectly distinguishable. And if we later decide to increase the opacity value to 255, we get [ 255 , 128 , 10 , 255 ] and [ 253 , 129 , 14 , 255 ]. That means less processing (only the alpha value needs to be changed) and no loss of information or quality.
Of course, normal computer monitors can't display transparent pixels; the software (or the graphics processor) must still calculate the resulting color of each pixel before putting it on the screen. And since most graphics cards work with 8 bits per channel, the data sent to the display will be exactly like the premultiplied example above: [ 25 , 13 , 1 ] for the first pixel and [ 25 , 13 , 1 ] for the second pixel. In other words, the pixels on the screen will still be identical. Using straight alpha won't magically give us more intermediate tones on the monitor. But it will preserve all the information about the original colors, and it will let the software distinguish (internally) between pixels based on their original color, even if their "composited" (that is, final display) color is identical.
Compatibility problems arise when a file saved with one type of alpha channel (ex., white matte) is loaded into and used by a program that expects a different type of encoding (ex., black matte). You don't get an error message; instead the program will load the data, assume it's in the format it understands, and treat it as such. The result is dark (or discolored) fringes around object outlines, and strange color shifts in areas with intermediate opacity levels.
Let's look at what happens when there is a mismatch between the encoding of the source file and the way the software processes the file. Here I will use only the most common types of matte (things get even worse when colored mattes are used):
|Figure 2 - Straight alpha source|
|Figure 3 - White alpha matte source|
|Figure 4 - Black alpha matte source|
Note that the issue here isn't which one looks "nicer". Some people might find the outline in the black-as-white sample aesthetically pleasing. And some people might think the shifted colors in the white-as-black have a really cool "eighties' video clip" look. The point is that, given the original image (with orange-yellow text, a light blue rectangle, and no outlines), you only get the correct result if the processing mode matches the way the original image was encoded.
For most file formats there is no direct way to determine the type of matting used by a given image (i.e., that information is not written to the file headers or anywhere else), so it's frequently up to the user to pick the right option. Since the edge and color shift problems aren't always obvious in the small preview windows of video editing software, it's not uncommon to render a complete project only to find, at the end, that some title or logo used the wrong kind of matte, and seems to have been rendered by a VHS mixer from 1980. Occasional incorrect matting artifacts can even be found in some "big budget" TV series.