[Bf-committers] Color space and alpha issues

gespertino at gmail.com gespertino at gmail.com
Wed Dec 21 17:14:46 CET 2011


2011/12/21 James Ruan <ruanbeihong at gmail.com>:
> Thanks for clearing that. My understanding of emitting color is not
> right. In that system total transparent pixel can have a color that
> means the emit of light. And that is allowed in the compositing. I
> wonder how to convert it (associated RGBA(1,1,0,0) )to the
> unassociated format since divide by zero problem. So is it really
> common to introduce emitting color system into image compositing?

Why divide by zero? The porter-duff alpha composite operation is an
addition. The second operator's transparent areas have to be zero in
some point, unless you really want to add something (like light).
The luminescent premul is not as common as other compositing cases,
but a nodal compositing system should be designed to allow artists to
do common and uncommon things as well.
It may be uncommon, but not rare. Take the example of the candle: you
mask a candle with its flame shot against a black background, and you
want to keep the glow around the flame. It's impossible if alpha it's
used as a mask.

But forget about luminescent pixels, try to understand what Troy
explained about convolutions on unassociated alpha and Brecht also
explained in a previous message.
Every operation that implies blurring pixels has to be done with
associated alpha to prevent background contamination on the filtered
foreground pixels.
When you're using OSA it's specially evident, since antialias is
performed prior compositing. Antialias is a convolution, when you
scale and rotate bitmaps the filtering is also a type of convolution,
and that makes background contaminate foreground if you're not using
associated alpha.

Notice also that "premultiplied alpha" is a tricky term and it would
be more appropriate to use the term "associated alpha". Premultiply
seems to imply that the alpha channel is multiplied over a clean plate
and it's not always true.
Associated alpha actually dictates how it has to be considered when
it's processed rather than saying how image was created.

So, answering the first question raised by Brecht, +1 to use
associated alpha as reference mode for the internals, but also +1 for
toggles (I/O selectors, alpha convert nodes, etc.) to give users full
control over the operations.
If internal flags are used for tagging alpha in image buffers, it
should be also displayed in the UI to allow users to track alpha
conversions (maybe using different colors for the RGBA sockets in
nodes?).
+1 also to get rid of the term "key" referring to unassociated alpha.
The alpha convert node should use something more accurate and
familiar.
I'd also like to propose an idea that hasn't been discussed: What to
do with the "sky" alpha mode? IMHO, that mode is extremely misleading
and the source of a huge deal of bad composites.
What about removing that mode completely, and compositing over sky
only when the "use nodes" checkbox isn't marked in the compositing
view? Then, if "use nodes" is checked, blender will use premultiplied
or straight, honoring the selected option in the shading section of
the rendering panel.
Sky is almost useless for compositing (there are some rare cases that
need colored mattes, but it would be easy to create them from a
premultiplied render) and it's more likely to confuse users if it's
the default option.


More information about the Bf-committers mailing list