So, I decided to go and have a look at the variables and you can either work in the standard 8bit, or a custom floating 16 bit, or a custom floating 32 bit. So, tomorrow I'm going to set up a custom template to a floating 32 bit.
Did you find these settings in Motion? I took a quick look around and didn't find anything under preferences. Maybe it's in project settings? From what I've seen so far, Motion is only doing 8 bit RGB.
Although there are other ways to handle alpha compositing, the world seems to have settled in 2 camps; non-premultiplied, in which case the image stores full color information plus a channel for an alpha (opacity) value. The color information stays the same, regardless of alpha value.
The 2nd camp is premultiplied [black] alpha. The alpha value is still stored in it's own channel representing opacity, but the color values are altered according the the alpha value using a formula like the following ...
for 8bit color and alpha channels (range 0-255); premultiplied_color=(color * alpha)/255; Essentially, this darkens the color as alpha moves towards zero. When alpha is zero, the premultiplied value will always be zero (black). This makes for faster compositing, because the graphics engine (most often the GPU) simply adds the color values and divides by 2. You could say the alpha is computed into the color channels, reducing computational complexity for display and also cutting down on the amount of information that needs to be sent to the GPU (alpha channel can be discarded).
When generating graphics in a CG tool, you generally have the option of outputting premultiplied (black/white) alpha, or non-premultiplied alpha. I can't think of a case when you'd want premultiplied over white, but that is sort of like the opposite of premult-black. AFAIK it's not used in any or the tools we generally use. If you are taking your animation into After Effects, you want non-premultiplied alpha, but for FCP or Motion, premultiplied is what works best. I believe you can tell FCP that you have straight alpha (non premultiplied), and it will do the premultiplication for you, but you want to specify that in the alpha type under the modify menu.
Essentially, the losses aren't that great until you get closer to transparent, but they are always there. If you started with 3, divide by 2 and round the result, then multiply by 2, you'll never get back to 3. You'll end up with either 2 or 4 depending on which way you rounded the result. Using 16 bit values, you can afford some losses, because in the end, you're going to round everything off to an 8bit value, anyway. Using 32bit floating point, it would only be a problem when you get very close to zero alpha. Of course, at zero alpha, you won't see anything anyway.
Here is where it gets you ....
Let's just say you decide to add a garbage matte to your chroma-key shot and feather the edges of the matte. You've just created a range of alpha values where the edge is feathered.
Now you add your chroma key filter which is reliant on color information for producing a key. At the fringes of your feathered matte, the color information has been all but obliterated by premultiplication with low alpha values. Those areas probably won't key out, because the chroma keyer will seem them as dark and lacking in color. So, you end up with a halo that tracks along the edges of your garbage matte. The simple solution would be to garbage matte after the chroma-key, but you may not know to do that, if you didn't understand where that stupid halo was coming from.
Here is another real-world case that forced me to add a feature to my vector keyer that I originally wanted to add as a separate plug-in. I created a shadow isolation tool that would pick out the shadows that fall in the transparent part of your chroma-key shot. i.e. the shadows that fall on the green screen. This allows me to create a shadow mask that you can apply to your new background so it looks like your subject is casting it's shadow on the new background, and you can adjust the shadow density, etc. I had the thing written, when I realized that the place where I needed to find shadows and do calculations had no color information whatsoever, because the keyer had premultiplied the entire region to black. So, I put the shadow generator in the keyer so it could work between the alpha calculation and premultiplication steps to find the shadows that would be removed by the keyer.
I'm sure in a compositing environment like Shake or AE, there are many tools that need color information from transparent regions for similar functions. So maybe the issue is more of a limitation as to what tools you can get for FCP rather than color quality in a typical workflow. Either way, I hate premult alpha, because it adds steps to the keying process and potentially discards useful color information before you are finished with it!
If you ever see unnaturally bright edges on something that has a feathered alpha channel, it is probably because the compositor expects premult alpha when the image is straight alpha. The regions that are 100% transparent or 100% opaque are fine, but everything in between (usually along the edges of an opaque area) will appear brighter than it should.
Doug
