Need help with Card3D alpha


I’ve been enjoying the Card3D node for a day now. I love that I can import camera and geometry transform animation from Blender (via .chan files)! The node is fairly easy to learn and use. However, there’s an issue with alpha. Whenever I try to Merge over (or any merge, that can use alpha, really) I get the alpha of the bounding box, but not the actual card shape in ‘3D’ space. Am I doing something wrong, or missing something? Is full alpha functionality missing, at this time? Is there a workflow that one can recommend?

Any help would be appreciated.


Ah, well… to answer my own question, all I had to do was to go to the image Read node and change Output Components from RGB to RGBA and - like that - alpha works. I guess it wasn’t working automatically on import because the test image was a JPG (which means no alpha), so RGBA wasn’t being toggled automatically.

I hope this helps other users. Any other insights would be welcome.


This Output Component stuff is a misconception of Natron.
A pain in the ass to say it quickly.

Here is a way to fix that.

Download this archive : (4.5 KB)

Extract the content in :

C:\Users[user name].Natron

Restart Natron.
It also does a few other useful things.


What would you do differently ? The default value should reflect what’s in the file, but the user can still choose whether this is RGBA, RGB or Alpha.
That’s why in Shuffle we have 2 different drop-downs: the “Plane” which is the name of the image plane (Color, UV, depth, diffuse, glossy, etc…) And the “Output Components” which is the number of pixel channels (1-4) that the plane has (UV = 2 channel, Depth = 1 channel, etc…)
The “Color” plane is a special plane that can be any of 1 to 4 channels (RGBA=4, RGB=3, Alpha=1).
Does that make sense ?


Hi MrKepzie.

as you said, the Output Component reflects what’s inside the imported file.
So far, there’s nothing wrong about that.
Problems occurs when using some nodes, the aformentioned 3D Card is one
It reflects an issue about how Natron deals with the alpha channel when an
imported read doesn’t have one.
We assume that when an image/sequence is imported, Natron fills the default
Layers (RGBA, Backward, Forward, etc…) with what it finds within the Read.
If, for exemple, there’s no Backward information in the file(s), it fills
this layer with black. So it does the same with the alpha channel.
You’ll notice that, in practice, there’s no difference between a Read node
without alpha (RGB) and the same Read with a black alpha (RGBA).
But in Natron there is one, when using Shadertoy for exemple.
Although the script i wrote outputs an alpha, because the Read node doesn’t
have one, if i put a Premult node just after, the alpha is simply gonna be
But as soon as the Read is explicitly set to RGBA, it works
That’s why i was talking about misconception.

So, if I was to make a suggestion, i would say there are 2 options :

  1. Remove that Output Component feature. I, personnaly don’t see any use to
    it, but there may be one.
    For exemple reading only the alpha channel from a sequence and therefore,
    ignoring the other channels, may reduce memory usage.
    Maybe was that the reason why you implemented it.
    I notice that in Nuke, there is no such feature. Everything is processed in
    In Fusion neither as far as I can remember. Everything is processed in RGBA.
    In After Effects, wether you import a sequence with or without an alpha
    channel, as soon as you bring it into a comp, an alpha is automaticly
    generated. Everything is processed in RGBA.
    In Flame it’s different, so it can’t really be compared but still,
    everything is processed in RGBA.

  2. Keep the Output Component feature.
    But then, make any Read (RGB or RGBA) to be processed as RGBA.

Anyway, with my simple file, I set any Read to RGBA in order for
Natron to work as expected.
So in the end, it works. :slight_smile:

2018-01-30 9:29 GMT+01:00 Alexandre Gauthier-Foichat <>:


Regarding RGB vs. RGBA there’s something more:
RGB is always considered opaque, i.e: Alpha = 1
When converting an opaque RGB file to RGBA, Natron fills the alpha channel with 1. Nuke does the opposite, by default it fills alpha with 0 (unless you check auto_alpha)
However in some situations (which I don’t remember right now) we figured it was more complicated to have alpha to 0.
Supporting RGB allows for a lower memory footprint of the Read node cache: instead of storing a pretty useless image channel full of 0 or 1, we generate it on the fly when needed below in the tree.
If you have arguments as to why it should be another way, please explain me


I do agree with you about lowering memory footprint by setting a Read node to RGB when there’s no Alpha.
It’s clever.
I don’t understand how RGB could always be considered having an alpha at 1.
I import a sequence in RGB, i look at the alpha. It’s 0, not 1.
I merge it over any background. It does (as expected) additive blending, because there’s no alpha.
There’s something i don’t get here.
The problem occurs when nodes don’t want to use the on the fly generated alpha because the Read node doesn’t have one natively.
That’s the only problem actually. But it may also be a bug. I don’t know.


When the Merge nodes has both the A or B input with RGB data, it by defaults uncheck the Alpha Channel checkbox (for A or B)

  • So If A and B are RGB, the result of a Merge with the over operation is: A+B (1 - 0) = A+ B (i.e: Plus):

  • If A alpha is set to 1 by checking the Alpha checkbox, then the over operation is : A + B (1-1)

Now, if the read node is set to Output Components RGBA, but the file is RGB, we convert to Alpha = 1, so it results to case 2) above.
However if we were to set Alpha = 0 by default, it would result in case 1) above by default.

If you come across something that looks ambiguous to you in a simple example, please post it so we can try to make it simpler.


OK, i’ll post an exemple by this evening, because i think I have some difficulties explaining my problem :slight_smile:
But it has nothing to do with the merge anyway.


As someone who started compositing in the NLE, then moved to After Effects and then Nuke before coming to Natron, I think the way Natron handles alphas - especially with footage that has no alpha- needs to be publicized more. I spent two years thinking the whole thing was a bug before it finally became clear. That’s two years of frustration because I didn’t understand that it does things differently. That’s why I finally made a video about it, hopefully new converts will see that and not be confused or frustrated like I was. A new convert will just think “I should be able to put this over my background, why isn’t it working?”

I agree - now that I understand it - that it is a smart way to save memory. It just needs to be clear to a new user that this is how it works.

The website needs a “Natron Basics” sort of page where there’s a few helpful pointers and/or videos to help people get started. Alphas should definitely be at the top of that list.


OK, here we go.
I have a simple image, imported as RGB, that I grade to get values above 1 (this man’s shoulder for exemple) :

Just after the grade node, I use a Shadertoy that generates an alpha channel based on the RGB values above 1.
It’s a basic luminance keyer in some way. It also fills the RGB with a constant color (red in this case).

Now, if I add a premult node just after the Shadertoy, i would expect the constant red color to be multiplied by the alpha, right ?
But that’s not what happens. The premult node does nothing, excepted turning the alpha to constant white.
It’s just as if the ‘on the fly’ alpha generated by the Shadertoy was ignored.

Now here is the odd thing. If I ever change the Read ‘Output components’ from RGB to RGBA, then I get the expected result : a solid red multiplied by the alpha.

So you see, it not about knowing if it’s a good idea to save memory by discarding the alpha channel when it’s empty.
If that can save a few megs, why not ? It’s just just that I get different results depending on that RGB/RGBA option.
And it should output the exact same result.


Here is the outputed alpha (clamped of course) :


And here the expectd result (only if the Read is set to RGBA ) :


I am very glad I asked this question and brought this issue to the fore. This discussion will lead to a resolution to this perceived problem. Although, I do agree that a lack of documentation had led me down a number of perplexing roads with Natron. However, yes, once you ‘get it’, it does what it’s supposed to.

I’m hoping that a human usability solution will be achieved on this particular item of peculiarity. Meanwhile, I’m following closely and learning a lot from this thread alone.


@fabiof17 Problem is that Shadertoy only outputs RGBA if input is RGBA, otherwise it outputs RGB. I might see it being an issue of Shadertoy actually rather than of the Read node itself