James Ruan <[email protected]> wrote: > The use of premultiplied alpha format is to save some computing time.
This is certainly a byproduct, but not entirely correct for associated alpha's existence. It is mandatory state for correct convolution operations and luminescent over adds. Jeremy Selan (lead architect on OCIO): "First off, I'm 'pro' premultiplication. To the best of my understanding, premultiplication is the natural representation of pixels with alpha; the big confusing thing about it is the name I feel the simplest understanding of premultiplication is looking at it from a rendering perspective. If you're writing a renderer, you ask yourself "how much energy is being emitted from within the bounds of this pixel"? Call that rgb. "and, how much of the background does this pixel occlude?" That's alpha. This is how all renderers work (prman, arnold, etc) , and its called 'premultiplied'. Note that at no time does prman have an explicit step that multiplies rgb by alpha, it's implicit in our definition of 'total pixel energy'. " http://groups.google.com/group/ocio-dev/browse_thread/thread/65e84a85416a8637/962ea485d1a210a3?lnk=gst&q=thoughts+on+alpha#962ea485d1a210a3 Brecht Van Lommel <[email protected]> wrote: "Both have some annoying consequences, I'm still going back and forth on this..." I think the discussion is really a yin / yang of balance. If we evaluate it on the merits of existing technology, it would seem that a sizable chunk of imaging systems default to the rendering model of associated. My only opinion on it is that if we go associated, that keying nodes and functionality still support unassociated as it makes it possible to manually recover the background plate data. If we enforce an "associated alpha throughout" am I correct in assuming that the output from such a node would default to a loss of that background plate data? With respect, TJS _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
