--- Operating System, Graphics card ---
Debian AMD64, Radeon HD6850
--- Blender version with error, and version that worked ---
Bug in 2.66; worked in 2.65a
--- Short description of error ---
The "Color Mix Node" produces a halo when mixing using the Alpha of the second channel.
In the "Alpha Over Node" I have to deactivate "Convert Premul" to achieve the same results as in 2.65a.
--- Steps for others to reproduce the error (preferably based on attached .blend file) ---
I added a blend file. There is included a packed 8 bit PNG with straight alpha.
Just open it in 2.66 and in 2.65 and compare the compositor results by clicking on the Viewer Nodes.
--- Operating System, Graphics card ---
This is not a bug, but rather a consequence of the alpha changes in 2.66. See the release notes here:
Your nodetree assumes that the image you are using is straight alpha, which was true in 2.65,
but 2.66 tries to keep float buffers premultiplied and 8bit byte buffers unpremultiplied. The
compositor works in float, so your 8bit straight alpha image gets premultiplied when used by
the compositor. If you want to use the same nodetree as before simply unpremult after the image
node. (Note that this is an improvement because now your nodetree will also work with
premultiplied exr files for example, which it did not in 2.65)
hope this helps, David.
Okay this explains the "Alpha Over Node", but "Color Mix Node" with the option "Include Alpha of second input" still produces incorrect results.
If it is the intended behavior maybe this button on the "Color Mix Node" should be removed and users would have to use the "Alpha Over Node" for all alpha-blending?
The mix operation does a linear blend between its inputs, i.e. output = (1-fac)*input1 + fac*input2.
If include alpha is enabled, this corresponds to a composite assuming input2 is unpremult
(obviously, as it is multiplied by fac). None of this changed between 2.65 and 2.66. Only
the image is now not unpremult anymore coming from the Image node.
Note that I would not be opposed to redefining the mix operation to be output = (1-fac)*input + input2
as the compositor generally assumes inputs to be premultiplied. Alternatively an additional "over"
operation with this logic could be added to the mix node.
Well, very much everything was already described by David.
It is indeed all the buffers are properly alpha-premultiplied in compositor and they indeed were straight in older versions of blender. That's why you need to disable "Convert Premul" for alpha over nodes -- you don't need to premultiply inputs extra time.
Not sure what's the best to do here to increase compatibility level apart from automatically adding Alpha Convert nodes for byte images. But don't think it's so much great thing to do. It could also be an option of Image Input node which will indicate "I want output of this node have straight alpha", displaying in N panel only and enabled for byte images saved before alpha pipeline cleanup commit.
For mix node i'd agree current behavior is odd. You couldn't actually mix two render results properly. I'm thinking of adding option like "Do linear blending" enabled for older files and disabled fore new ones, and change default behavior in a way David proposed.
Robert, unfortunately nope. This nodes could eb used for other purposes like alpha overing keying result (which you would need to premultiply) on a background. I'm currently working on a patch which shall make files more compatible.
Added compatibility option "Straight Alpha Output" to image input node. When this option is enabled, image input node will convert float buffer to straight alpha and behavior of node tree would be the same as it was in 2.65. This option is available in N-panel.
Patch was commited to svn rev54960.
Now if you'll save the file in 2.65 and open it in trunk compo result should match.
As for Mix node -- we've spen quite a while discussing it today. It's likely be implemented as ether separate node or mix type, but that's not directly related to this bug report. Alpha flow in compositor still needs some rethinking and it's in TODO lists of mine and Ton.
Thanks for the report and comments, but would consider actual bug fixed now.