2011/12/21 James Ruan <[email protected]>: > 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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
