[Bf-committers] Color space and alpha issues

[Troy Sobotka]

James Ruan <ruanbeihong at gmail.com> 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 <brechtvanlommel at pandora.be> 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