Warp <war### [at] tagpovrayorg> wrote:
>   I can't understand why this was reverted. Maybe the reason for the 3.6
> behavior has been forgotten?

If it really doesn't work even with "transmit" set on the background, then I'd
expect so. After all, the PNG spec explicitly states:

"The color values stored for a pixel are not affected by the alpha value
assigned to the pixel. This rule is sometimes called "unassociated" or
"non-premultiplied" alpha. (Another common technique is to store sample values
premultiplied by the alpha fraction; in effect, such an image is already
composited against a black background. PNG does not use premultiplied alpha.)"

So even with a black background, mixing that in would be the wrong way to do it.

There may be a rationale behind the new 3.7 behavior: In a non-anti-aliased
shot, apps that don't support alpha would display the original background.
However, this rationale breaks down as soon as anti-aliasing comes into play,
or semi-transparent objects. And it violates the specs.

So wherever the background is mixed in, alpha must be set to fully opaque there.
That's a clear one for PNG.

Which hints at another problem with the new 3.7 behavior: It seems that this is
dealt with in the backend; but a look at the PNG spec indicates that it is in
fact a file-format dependent issue, and should therefore be handled in the
frontend.

Post a reply to this message