0
$\begingroup$

I'm working on a video in the sequencer, and as part of this I want to overlay a scene containing some text. The text is rendered via node-based shading, and in particular uses a "clouds" texture to define the alpha-value of the final composite.

If I render the scene by itself, or set the relevant scene-strip to render using a mode like "replace", all looks as expected. See here:

eTransparency as expected

However, if I set the scene-strip to render using the "alpha-over" mode, then I get a strange artefact: in places where the scene is completely transparent, I see the colour of whatever was present there (if anything), and using what looks to be additive blending!

Here you can see the same text rendered over a simple blank "colour" strip:

Odd transparency

And here over a video-strip; note how the areas that one might expect to be fully-transparent seem to "glow" against the background colour, as though blended additively:

Odd and glowy transparency

I'm really stuck as to what might be causing this.

It looks almost as though, when presented with an alpha-value of zero, the "alpha-over" blending switches to blending the RGB colour additively with full alpha--but that makes little sense.

It also occurred to me that perhaps I was getting negative alpha-values due to the application of the "clouds" texture, and in particular my handling of it.

But if that were so, I would expect simple high-opacity rendering, not this odd additive-like rendering. And furthermore, the alpha-values go through a "math" node that has the "clamp" check-box ticked, so it should, presumably, only be getting values between 0 and 1.

So I'm stuck. Does anyone here know what might be the problem, and how I might fix it? :/

[edit] Oh, I forgot to mention: this is using Blender 2.78c, I believe.

[edit 2] Amusingly, the actual additive-blending strip-mode works as expected, with fully-transparent areas being invisible.

[edit 3] I've also discovered that I can get the expected result if I place the background on top of the text-scene and set the former to use the "alpha under" mode. If called for, this might at least provide a workaround.

[edit 4] It seems that if I add a very small amount to the final alpha-value given to the "composite" node in my "compositing" node-system, the problem disappears. It really does look like there's an issue with alpha values of zero, specifically, for some reason. o_0

[edit 5] A stripped-down version of the blend-file: Test Blend-file

In this version, there's just a simple plane being rendered over a colour-strip. Note that, when the scene alone is rendered in the "Default" layout, it has transparency as expected. However, when rendered as part of the video in the "Video Editing" layout, the transparency shows the above-described issue.

Video Editing is set up in the "Video Editing" layout, and compositing in the "Default" layout.

Improve this question
$\endgroup$
5
  • $\begingroup$ Hmm... Which are those? The closest that I see right now is the "Use Alpha" check-box in the final "composite" node for the scene that contains the text. I may be missing an option, but I don't see a premultiplication option in my scene-strips. $\endgroup$
    – Thaumaturge
    Commented Nov 22, 2019 at 19:58
  • $\begingroup$ I misunderstood. Could you add a condensed version of your file? $\endgroup$
    – Leander
    Commented Nov 22, 2019 at 20:30
  • $\begingroup$ Sure. I've edited the original post with the file. $\endgroup$
    – Thaumaturge
    Commented Nov 22, 2019 at 21:10
  • $\begingroup$ You are manually setting the alpha channel, but you are not premultiplying the rgb channels. I'd advise you to use the builtin nodes for premultiplication. $\endgroup$
    – Leander
    Commented Nov 22, 2019 at 22:25
  • $\begingroup$ Ah, you're quite right! Thank you very much for that! :D (And I'll admit that I wasn't aware of the "alpha convert" node.) I'll admit that the behaviour without premultiplication still feels unexpected, but I'm glad to have a solution to the problem! (And one that's less hacky than my "add a very very small amount to the alpha" solution.) <edit> PS: Please repeat your response in an answer, so that I can accept it! ^_^ $\endgroup$
    – Thaumaturge
    Commented Nov 22, 2019 at 23:00

1 Answer 1

Reset to default
0
$\begingroup$

You're combining rgb values and an alpha, without premultiplying rgb values.

You can use the builtin Alpha Convert node, to do the premultiplication.

node setup

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thank you very much for the answer! As noted in my other comment, this does indeed work, and I've marked this as answering my question. ^_^ $\endgroup$
    – Thaumaturge
    Commented Nov 22, 2019 at 23:17
  • $\begingroup$ @Thaumaturge However, I still can't quite explain the other result as well. $\endgroup$
    – Leander
    Commented Nov 22, 2019 at 23:22
  • $\begingroup$ Yup. It's... really weird. :/ Why would an alpha of 0.000001 be treated significantly differently than an alpha of 0? o_0 I would understand if it were discarding colour-information in 0-alpha pixels for the sake of conserving resources--but that doesn't appear to be what's going on here. $\endgroup$
    – Thaumaturge
    Commented Nov 23, 2019 at 0:19
  • $\begingroup$ As an additional “it makes sense”, associated alpha, or the horrible term premultiplied, models both occlusion and emission. That is, in your example where you say that something has zero alpha and still emits, it’s a perfectly valid case! It represents an emitting source that isn’t occluding the background, such as a candle flame, flare, glare, or glow. $\endgroup$
    – troy_s
    Commented Nov 23, 2019 at 6:47
  • $\begingroup$ Hmm, I see--and thank you for the explanation! So, am I correct in gathering then that the rendering process was automatically pre-multiplying areas with non-zero alpha, but not doing so for other areas? That would explain the behaviour, with areas of non-zero alpha being non-emissive, and areas of zero alpha being emissive--but it seems very odd to render the two so differently! $\endgroup$
    – Thaumaturge
    Commented Nov 23, 2019 at 14:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .