File Output node output is different from what is seen in the viewer node #37562

New Issue

gandalf3 · 2013-11-21T04:30:40+01:00

gandalf3 commented

2013-11-21 04:30:40 +01:00

System Information
Archlinux
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 file_output_auto_stack.blend

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

**System Information** Archlinux 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 [file_output_auto_stack.blend](https://archive.blender.org/developer/F29783/file_output_auto_stack.blend) 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

gandalf3 commented

2013-11-21 04:30:40 +01:00

Changed status to: 'Open'

gandalf3 commented

2013-11-21 04:30:40 +01:00

Added subscriber: @gandalf3

Thomas Dinges commented

2013-11-21 07:53:45 +01:00

Added subscriber: @ThomasDinges

Thomas Dinges commented

2013-11-21 07:53:45 +01:00

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

gandalf3 commented

2013-11-21 09:22:07 +01:00

It does happen in the official blender.org build, r60991

Lukas Tönne commented

2013-11-21 11:22:52 +01:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2013-11-21 11:22:52 +01:00

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.

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.

gandalf3 commented

2013-11-21 20:13:14 +01:00

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: http://blender.stackexchange.com/q/5017/599

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.

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: http://blender.stackexchange.com/q/5017/599 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.

Leon Cheung commented

2013-11-21 20:50:40 +01:00

Added subscriber: @ZhangYu

Leon Cheung commented

2013-11-21 20:50:40 +01:00

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:

Open gandalf3's file, link Viewer node to Image,
Switch File Output format from png RGB to RGBA;
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.

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.

gandalf3 commented

2013-11-21 22:26:18 +01:00

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:
http://www.pasteall.org/pic/62922

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 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: http://www.pasteall.org/pic/62922 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.

Lukas Tönne commented

2013-11-22 09:38:52 +01:00

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 Tönne self-assigned this 2013-11-22 09:39:37 +01:00

Leon Cheung commented

2013-11-22 10:01:44 +01:00

@gandalf3, When I say "thefirst 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.

@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 Tönne commented

2014-07-08 18:16:38 +02:00

Changed status from 'Open' to: 'Archived'

Lukas Tönne closed this issue

2014-07-08 18:16:38 +02:00

Lukas Tönne commented

2014-07-08 18:16:38 +02:00

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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

File Output node output is different from what is seen in the viewer node #37562