Why are alpha channel images rendering with white outlines?

Hi all.

When I read in a PNG image with an alpha channel and try to render it over another image (or video) I get white lines around the edge of the overlap. I note that this question was posed previously in 2018 but there were no solutions.

I have created a PNG image with a transparent section in GIMP:

gimp

Which I then import into Natron, apply some color correction, then merge over a background image:

I’ve tried using various merge types (and also Chromakey) but every time I render the output, I get white edges around the ‘join’:

(In fact, the rendered output looks nothing like the preview window at all - the foreground arch has rendered as a black silhouette).

Can anyone see what I’m doing wrong? I’ve played around with alpha channel and premultiply settings (I saw that mentioned somewhere) but nothing solves the problem.

Many thanks.

it’s an alpha premultiplication issue. You’re probably merging over a transparent image, and when writing the PNG Natron divides RGB by alpha (because PNG has unpremultiplied alpha)

Verify the settings of your Merge node, the A channel for the B input is probably unckecked, meaning it’s 0. We should probably change that default behaviour to using A if the B input is opaque

I propose a change to fix that (buggy) default behavior: Merge: never consider RGB as being transparent by default. by devernay · Pull Request #78 · NatronGitHub/openfx-misc · GitHub

1 Like

Nuke has a good feature that fixes a similar problem which is the “auto alpha” checkbox in the read node that will flood the alpha channel. I don’t think Natron has this and I’ve also seen people get confused by this problem. Including this in the read node and automatically turning it on for images or sequences that have no alpha data whatsoever seems like the best fix to me? At the very least if you don’t want to write a whole thing to detect alpha in the sequence hardcoding a whitelist of formats (DPX & JPEG for example) would be another way to go about adding this. I would also say that as a general rule EXR sequences should probably be excluded from this behavior unless they only contain RGB channels.

Additionally I never liked the name “auto alpha” because what does “automatic alpha” even mean? It’s not automatic, this is actually a thing you always have to check on manually if you want to use it. “Flood alpha” seems like a much better name to me. It’s also not automatically turned on in the way I’ve suggested above.

1 Like

Yes, the B input in the merge node was unchecked - enabling it does seem to have fixed the problem.

Many thanks, Frédéric.

So the proposed beaviour is that an RGB image that has no alpha is assumed to have an alpha that is 1 for all pixels?
If so: :+1:

this is what we tried to do with the “outputcomponents”, so RGB input would be transparent, and RGBA output would be opaque.

However, I think that “auto alpha” setting is pure nonsense: an RGB image with alpha=0 makes no sense in premultiplied compositing, since many operations (eg colorspace change) involve dividing by alpha.

This leads to erroneous compositing graphs, and unfortunately the “BayMax” sample project we distribute with Natron has that kind of nonsense alpha values.

My opinion is that RGB images should be considered opaque by default, and the informed user should explicitly zero-out alpha if required (using a shuffle node). But I still maintain this is nonsense. Tom Porter and Tom Duff would probably approve.

If I’m not mistaken, with this solution images and content in the graph that has no alpha channel are treated as if it does on merge. I agree that plates brought into the graph typically should be treated as opaque by default if the format does not support alpha channels. Implementing this in the merge node instead of the read node creates a system that is not transparent (get it!) for the user. If users want images to be opaque and act as physical objects in terms of light transport those images should have alpha channels applied in a way where they can see that is the case, not magically on merge—despite the fact that both of these have the same outcome. Porter & Duff lay this out clearly, RGB consists of the emissive values of a pixel whereas alpha represents a percentage of geometric occlusion.

The user should be informed that an alpha channel exists, that has been made for them on read, and that their image will be occluded accordingly.

Additionally, there is content in pre-multiplied compositing that does not (and should not) have alpha channels, notably emission and reflection passes which cannot have alpha channels because light has no mass and cannot occlude objects in this way.

Changing how the Output Components dropdown functions is a great solution to this issue. Right now it doesn’t automatically assign alphas when reading formats that do not support them. It also doesn’t have a clear name, at first glace to me it seems like I’m changing what information that is encoded in the file gets output to the graph. Replacing it with a “flood alpha” checkbox that has sensible defaults based on filetype is, in my opinion, the ideal solution for both consistency within the program and support for the alpha channel standard implementation overall.

2 Likes