5
$\begingroup$

If I Gaussian Blur white, I get white. No surprise.

GaussBlur(White) = White

If I then pipe this through a Mix node with any other color—say, yellow—the output is black.

Mix(any, GaussBlur(White), Fac=1.000) = Black

I'm baffled. Why does this happen?

This is with the default scene settings, just switched to Cycles.

It also happens if I pass the blur through Separate RGBA and Combine RGBA first, but I've verified that each of the channels is at 1.000 (by sending them directly to the Composite node's image, which appears white). It doesn't work if I swap out the Blur node for an RGB node with pure white.

It does not happen if I check the "include alpha of second input" box on the mix node; in that case, the base color is used and the blur input is ignored.

Reproduced on Mac 10.10.3 and Linux Mint 17.2.

Bug?

$\endgroup$
  • $\begingroup$ What are you trying to accomplish? With no image input on the blur node this set up makes no sense to me. I see no bug... $\endgroup$ – cegaton Jul 14 '15 at 18:08
  • 1
    $\begingroup$ I think the mix node is not evaluated at all in the second case could be some check inside node that checks the dimension of the inputs images, if you pass the blur through scale node and set a valid size it will work also if you attach any image in the other input ( like the render layer ) it will work also, so basically the blur node is not passing a valid image size to the mix node which stops working without it. $\endgroup$ – Chebhou Jul 14 '15 at 18:18
  • $\begingroup$ Related: blender.stackexchange.com/q/2376/599, and another bug report: developer.blender.org/T36472 $\endgroup$ – gandalf3 Jul 14 '15 at 18:38
  • $\begingroup$ @cegaton I expected that the blur input would be equivalent to blurring an all-white image. This post is, of course, an MWE. Here's my actual node setup. It gets input from a Python script, and either uses an image input node or not. If not, it just uses a white input. The "Play Button Overlay" group has the Blur–Mix node combination inside it. I figured that this setup would be sufficient to specify "blur the image or just use (blurred) white." I guess not. $\endgroup$ – wchargin Jul 14 '15 at 18:50
8
$\begingroup$

From this bug report:

When the input image file is not available, what happens is that the mix node will still try to use the resolution of the first input as the resolution of the output, which doesn't work well because the non-existent file specifies a (0,0) resolution - thus the black image (there are simply no pixels that would be mixed with the second input).

The mix node cannot detect cleanly whether the input buffer is valid, and the image node cannot guess a meaningful resolution ... It seems to work as expected if i choose a valid image file.

I would like to redesign the whole resolution handling in the compositor. Pixels are just not a very reliable and intuitive way of specifying size and transformation. When this happens we can hopefully avoid cases like this.

For context, this was reported while attempting to do this.

So essentially, the mix node (rather unexpectedly) doesn't know the size of the image it's getting from the blur node. As such, it treats it like the input from the blur node is completely transparent (or 0x0 pixels large).

One workaround is to provide a resolution, e.g. with a mask node:

enter image description here

$\endgroup$
  • $\begingroup$ Whoa, I never would have guessed this. Thanks a ton! $\endgroup$ – wchargin Jul 14 '15 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.