These are probably remnants and bad habits from unpremultiplied/unassociated compositing software (AE)
Actually the opposite is true, most of Adobe’s straight alpha nonsense results in 1110 type scenarios not being properly supported, much to my chagrin! RGB images can be opaque but RGB data can also be written (and regularly is written from within render engines) with A=0, while being completely valid in premultiplied compositing, EVEN when writing to formats that don’t support alphas!
In this post I will try to explain why this is the case and how it relates to Natron’s proposed compositing changes and what exactly I mean when I say that Foundry has gotten it right.
“The alpha channel of 0 indicates that this pixel will obscure nothing.”
Compositing Digital Images (1984) Thomas Porter, Tom Duff
The key word here is “obscure”. Porter-Duff compositing does not treat pixels with A=0 as simply “transparent”. Instead, the alpha channel denotes a percentage of geometric occlusion which isn’t just as simple as calling it “opacity” either, RGB channels denote the emissive value of a pixel as backed up by Jeremy Selan:
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’.
Thoughts on Alpha (2011) Jeremy Selan
Consider a pixel where rgb > alpha, such as 2.0, 2.0, 2.0, 1.0. Nothing special about this - it just represents a ‘specular’ pixel where it’s emitting 2.0 units of light, and is fully opaque. A pixel value of (2.0, 2.0, 2.0, 0.0)? Nothing special about this either, it represents a pixels that’s contributing 2.0 units of light energy, and happens to not occlude objects behind it. Both of these cases can cause trouble with unpremultiplied representations.
Thoughts on Alpha (2011) Jeremy Selan
Photons have no mass, they have no geometry, they physically cannot occlude things, therefore purely emissive pixels have no alpha value… but they do have RGB values!
The above contains my reasoning for the proposed implementation earlier in this thread:
-
Wanting to flood alpha for images that are read into Natron without alpha channels is noble and will save some headache for people who currently have to manually add alpha channels for their plates that are in formats that don’t support alpha channels (or perhaps more accurately, forget to do so). Chances are the objects in these images are solid objects and we can reasonably assume that all image formats read into Natron which cannot contain alphas should be solid and occlude anything placed behind them.
-
Simply dropping alpha when writing to formats that don’t support it is valid and correct. RGB=1 A=0 is a fully encoded white pixel (colourspace aside) and should be written out as 1 as long as nothing with an alpha is occluding it. Remember, PNG is broken, alpha is not just “transparency” or “opacity”, it’s a percentage of occlusion and if nothing is occluding it then it is fully emissive! Once I learned this it actually took me a while to wrap my head around this concept. It can feel somewhat counter-intuitive to the way we use alphas in practice to mask things.
-
Applying these flood operations automatically, by default, in merge nodes ignores the fact that RGB=1 A=0 is valid and makes a bunch of assumptions about the type of image being fed into the merge node.
In short, should the viewer display it? YES!