Page MenuHome

File Output node output is different from what is seen in the viewer node
Closed, InvalidPublic


System Information
Nvidia 7900GT

Blender Version
Broken: Blender 2.69 Release (from archlinux repos)

Short description of error

File written by the file output node is different from what is seen in the viewer node:

  • The viewer node sees the correct output, the output from the Renderlayer node.
  • The written file appears to be black.

Exact steps for others to reproduce the error
Based on

  1. Render frame one
  2. The viewer node displays the output of the mix node, which should be the same as the renderlayer node output. This works correctly.
  3. The File Output node outputs a black image to /tmp/image_stacking_test/asdf/render0001.png

Event Timeline

Ellwood Zwovic (gandalf3) raised the priority of this task from to 90.
Ellwood Zwovic (gandalf3) updated the task description. (Show Details)
Ellwood Zwovic (gandalf3) edited a custom field.

Please double check with our official Blender version from We had it in the past, that third party builds behaved wrong or had issues.

It does happen in the official build, r60991

Well, first of all the image file referenced here doesn't exist on my system obviously, so i can only guess if something is wrong with it.

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 can not detect cleanly whether the input buffer is valid, and the image node can not 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.

There isn't supposed to be any image file, the setup is supposed to automate render stacking.
After the first frame is rendered, it creates the file for the image sequence node to read.
See this for more detail on what the node setup is supposed to do:

The first image is supposed to be a mix of nothing and the straight render with a factor of 1 so only the straight render is used.

The strange thing is, it appears correctly in the viewer node.

IMHO, it seems not strictly a bug. That's because the offset value you set is -1, and the relevant frame# to that is 0000, which doesn't exist in the sequence folder, I'm afraid, which causes the Mix node cannot receive a valid data for the first image input. So, The image1 input got no alpha, which considered as an zero-Alpha image, which cannot mixed by the Mix node, since it doesn't currently support Alpha mix with Image1 input, which may be improved some?

I think a solution to your case is to render an image0000.png in step 4, which will solve the black issue, and no need to render from Frame 2, too.

Btw, I indeed met another problem which caused blender crashing (a real bug?), repeated as below:

  1. Open gandalf3's file, link Viewer node to Image,
  2. Switch File Output format from png RGB to RGBA;
  3. Alt click on the compositor background, crash happend.

If you cannot repeated, try use a valid local image with the same name as xxxx0001.png or something.

The mix node should not need to receive any image in the second image input, because on frame one the mix factor will be 1, meaning that the mixed result will be a mix of 100% bottom input. The top (missing) input is not needed, so it shouldn't have any affect on the output.

I'm not sure I understand what you mean by the alpha of the bottom input being zero, but it works fine in the viewer node:

EDIT: The reason it works fine in the viewer node is because the viewer does not display the image with the alpha channel by default. Enabling Use Alpha causes the background image to disappear.

The mix factor cannot be taken into account here because this is generally a variable per-pixel value, so it has to be evaluated for each pixel combination of the input images. The problem arises before this can actually be done, in the image node rather than the mix node. Compositor currently relies too much on resolution and has no way of detecting invalid inputs.

Lukas Toenne (lukastoenne) lowered the priority of this task from 90 to 50.

@Ellwood Zwovic (gandalf3), When I say "the first image (or image 1) in Mix node", I do mean the top image socket, which is the base image, not the bottom one. Sorry for confusing.

Lukas Toenne (lukastoenne) changed the task status from Unknown Status to Unknown Status.Jul 8 2014, 6:16 PM

Since this is a know design limitation without a quick solution, i will put this on TODO for now. The resolution system in the compositor needs a complete refactoring anyway.