Compositor: File Output node redesign

[OmarEmaraDev]

We are currently working on a redesign of the File Output node, but the final design is still not clear to us. So we are looking for feedback.

Multi-Layer vs Single Image

The node has two modes of working. It can either save the inputs as layers in a multi-layer EXR file or save each input in its own image file, like PNG. This introduces a number of problems.

Distinction

Problem

The distinction between the two modes is not very clear, because the mode change depending on the file format. If OpenEXR Multi-Layer is chosen, then the node acts in Multi-Layer mode, but for any other format, the node acts in single image mode.

To make matters worse, if Use Node Format is disabled for one of the inputs. The input’s file format still lists OpenEXR Multi-Layer, but it silently just behaves like the non-multi-layer EXR format.

Solution

Our proposed solution so far is to introduce a “Media Type” enum that lets you choose between Single Image and Multi-Layer.

If Single Image is chosen, then OpenEXR Multi-Layer will not be in the file format list.

Like-wise, if Multi-Layer Image, only OpenEXR Multi-Layer will be in the file format list.

Which I guess we can hide since it is the only format for now until we get more multi-layer formats if it ever happens.

It should be noted that this UI is shared between the Render Output and Save Image operators. So they too will likely get the “Media Type” enum. However, for the Render Output, an additional Movie media type will be available.

Base Path

The node has a “Base Path” option that is supposed to specify the path of the the files that will be written.

Problem

The Base Path option is a quite overloaded option and its meaning changes based on the node options.

• Sometimes it specifies the directory only, and the name of the file is specified by the name of the input. This is for single image files.
• Sometimes it specifies both the directory and the file name. This is for Multi-Layer files.
• Sometimes it specifies both the directory and a prefix for the file name, while the full file name is completed based on the name of the input. This is for single image files.

So users might not really be sure what the final name of file(s) will be.

Solution

The solution is two folds. First, we split the Base Path option into two options:

• Directory: Which only specifies the directory where the files will be written.
• File Name/File Name Prefix: Which specifies the file name for Multi-Layer images or the file name prefix for single images.

Second, we draw in the UI the final path of the file that will be written if a render was performed. But has a few complications. Mainly, the file output node might write multiple files if multi-view is enabled, so we will have to list multiple paths for each file that will be written.

Furthermore, the file path might be different depending on whether we are doing a single render or an animation render (As we will later see). So will we have to list both?

Finally, since Blender recently got variable substitutions. We might not be able to substitute every variable since it might depend on information only available during rendering.

Socket Names

Socket names define layer names in Multi-Layer mode and file names in single image mode.

Problem

Currently, the node keeps a separate name database for multi-layer and single image modes. So if you add a bunch of inputs and name them as you like, then you change to Multi-Layer mode, your names will revert back to their default values and you loose what you renamed, which can be frustrating.

Solution

We unify socket names to be consistent in the two modes, so changing the mode will have no effect on the socket names. However, if we do that, we will have to impose restrictions on what the name can be. For instance, file names can’t include special characters like > < " : and so on, so your EXR layer names can’t have those characters as well.

External Factors

Options like File Extensions in the scene Render Output panel affects the File Output node.

Problem

The fact that an option in scene render output settings affect the File Output is not at all clear.

Solution

The node should be self contained, and we should move such options to the node itself for clarity.

Frame Number

The File Output node always appends the frame number even if the render is not an animation.

Problem

Some people use the File Output node to do a single render, and they don’t like the fact that the frame number is always appended.

Solution

We don’t append the frame number unless the user is doing an animation render. However, we heared concerns that users might want to “replace a bad frame” after an animation render, so they do a single render in that frame expecting frame numbers. Otherwise, you will have to render a an animation with a single frame range.

---

Relevant tasks and discussions:

Compositor: Redesign File Output node

Fix #134920: File Output writes frame for single render

[kurk]

This sounds good. I think “save as render” shouldn’t be on by default for EXR renders.

[Kien_Nguyen]

I know this isn’t about the “File Output” node specifically but we need to have an option to disable the “Output” in the Properties editor when using the File Output node.

I always use the “File output” node to save out Multi layer EXRs so that i can have greater control over the layer names, etc. But there is no way to disable the “Output” in the properties editor so i constantly have to remember to set a path for it and remember to delete the content of that folder later which is very cumbersome. Even worse if the path matches the path in the file output node, the file from the file output node get replaced.

[thorn-neverwake]

@Kien_Nguyen

I know this isn’t about the “File Output” node specifically but we need to have an option to disable the “Output” in the Properties editor when using the File Output node.

Yes, please very much.

Overwrite Alert would be nice, too.

[txo]

So many things to consider! Overall, I think this is a very welcomed thing, the output node was lacking a lot of improvements. So, for starters, thank you very much!

---

multilayer vs single image

I think it better this way, specially the “use node format”, which in my experience wasn’t a very common mistake, but when for some reason happened to me, it took me a while to discover the reason. So, much better.
Kinda nitpicky, but I wonder if the term “single image” is the best, at first glance it may seem that it will only save one image. Maybe something like single layer would work better? I don’t know, I’m not an english native speaker, so…

---

Base path

This is the one I have most trouble getting. It points in the right direction, but it still feels confusing as you described it. Or maybe I’m not understanding it correctly?

The solution is two folds. First, we split the Base Path option into two options:

• Directory: Which only specifies the directory where the files will be written.
• File Name/File Name Prefix: Which specifies the file name for Multi-Layer images or the file name prefix for single images.

I’m not getting where’s the the split into two options. I see the properties textBox, which seems to include the whole Path/FileName structure in it.

If the first the “directory” part is referring to the node UI box…I don’t like that at all. I think it’s confusing, and also think that the name shouldn’t come from the “node name” (is it the label?). I think it is very weird.

I get the idea, but IMO the path/file inputs should all live either in the properties panel, or in the file output node. Maybe something more like this?

(It’s a very crude mockup, just to point out the idea). Anyway, I may be misreading your idea, sorry if I am.

---

Frame Number

The File Output node always appends the frame number even if the render is not an animation.
[…]
Solution
We don’t append the frame number unless the user is doing an animation render. However, we heared concerns that users might want to “replace a bad frame” after an animation render, so they do a single render in that frame expecting frame numbers. Otherwise, you will have to render a an animation with a single frame range.

I think it is a valid concern. But in the case that users are at the point of evaluating bad frames and overwriting them one at a time, to me it is a good enough solution to just provide a way to append the frame number via variable (_####), and let the user add it when it suits them.

Or put in an “always append frame number” checkbox, that toggles that variable automatically, if it’s a useful enough option to justify the arbitrariness of it?

---

Other

The only other thing I’m unclear is what has been decided regarding the conflict between node output and render properties output (the one in the main UI). I swear, I still feel like a noob sometimes when I have to set it up, I’m never sure if I’m setting something wrong.

But, as I said…much appreciated, it looks super promising!

[LudvikKoutny]

Yes, I second this. The unwanted frame number severely limits the usability of File Output node for outputting single images. Whether frame number is appended or not should be handled by some output name syntax.

[thorn-neverwake]

@txo

put in an “always append frame number” checkbox, that toggles that variable automatically, if it’s a useful enough option to justify the arbitrariness of it?

That is the simplest and most easily understood, effective solution.

Append Frame Number (X).

[SpookyDoom]

Not directly related to the output node, either, but if the topic gets discussed again I’d like to point to the problem of render layers needing to be stored in Memory before being written to disk. If the user sets up many render layers and renders at a high resolution Blender will fill and potantially overflow the RAM with all passes before processing and outputting anything to disk which can crash the program.

And it can be very hard to pin down as a user.

Direct render of individual ViewLayers to Disk. Current state produces Memory...

[txo]

I was thinking about it, and maybe something like this, some sort of enum list with variables, could make it a more general solution, and also to have output variables be more discoverable? I think Substance Painter has a similar thing in the export window, where you can append available variables to the name. I think that combined with the name preview below would work pretty good?

(again, this is very crude, sure there’s lots of things wrong, it’s just to get the idea across)

[ManuelGrad]

Fantastic proposal that addresses many shortcomings!

Scattered output settings

As others have already pointed out here, one of the biggest pain points currently is probably the conflict of having multiple active places where an output can be defined – with no way to disable the output from the render properties.

One possible solution could be never to allow multiple separate places that define output settings being active at the same time – once you enable the Compositor, the render properties output panel gets greyed out, its output will get disabled, and the functionality will be replaced by an equivalent comp setup with respective outputs.
This way, all the ambiguity is gone, and it’s very clear what’s happening. Plus, you don’t have to render mandatory dummy renders anymore (render properties output renders that you can’t disable).

Frame number

Not sure what happened to the path templates patch, but it looks like one of the most fundamental variables (framenumber) got removed at a late stage from the patch. Which is a shame because instead of having a consistent and logical way of defining the frame number as a variable using this new system, we now think of implementing arbitrary behaviour or adding weird options and toggles.

The time spent in implementing a weird solution with drop-down menus and separator string definitions and whatnot might be better spent in investigating this again, and finally having a frame number variable that can be used like this:

foo_{frame_number:####}_bar.exr

https://docs.blender.org/manual/en/4.5/files/file_paths.html#path-templates
https://projects.blender.org/blender/blender/pulls/134860

[txo]

@ManuelGrad

Not sure what happened to the path templates patch, but it looks like one of the most fundamental variables (framenumber) got removed at a late stage from the patch. Which is a shame because instead of having a consistent and logical way of defining the frame number as a variable using this new system, we now think of implementing arbitrary behaviour or adding weird options and toggles.

What? Really, it got scraped? Wow, that’s a shame. I completely agree, it was something I was definitely looking forward to have.

And, for the record, I agree with your take on “weirdness” about the toggle, it was just an idea; But in any case, it was based on the assumption that the frame number variable would exist. (And I like the enum idea better, honestly I think it has a more general approach to the “add variables to the file name” without having to remember the exact format)

Although surely the devs must have their reasons for having done so, I honestly think it should be brought back, it’s one of the must-have variables, without question.

[OmarEmaraDev]

@kurk

I think “save as render” shouldn’t be on by default for EXR renders.

It can be removed altogether for EXR as far as I can tell since EXR never apply view transforms.

@Kien_Nguyen

but we need to have an option to disable the “Output” in the Properties editor when using the File Output node.

This was being looked into by Habib. It is complicated, so we couldn’t find a straightforward solution. In any case, expect another feedback thread to discuss this independently. Relevant task:

Compositor: Render is saved twice when File Output node is used

@Kien_Nguyen

Even worse if the path matches the path in the file output node, the file from the file output node get replaced.

@thorn-neverwake

Overwrite Alert would be nice, too.

I suppose I can add a warning in the node indeed.

@txo

Kinda nitpicky, but I wonder if the term “single image” is the best, at first glance it may seem that it will only save one image. Maybe something like single layer would work better?

I don’t like the name myself as well. By initial preference was to use “Individual Images” or something similar. But the problem is that this will be shared with Render Output and Image Saving Operator, so we need to find a working that works for all.

@txo

I’m not getting where’s the the split into two options. I see the properties textBox, which seems to include the whole Path/FileName structure in it.

Sorry for the confusion, this is not implemented in the screenshot I posted. But it will be similar to what you have in your mockuop, as in, we will have two text boxes, one for the directory, and one for the name.

@txo

Or put in an “always append frame number” checkbox, that toggles that variable automatically, if it’s a useful enough option to justify the arbitrariness of it?

@thorn-neverwake

Append Frame Number (X).

@thorn-neverwake Just to clarify, that option would only control single renders, but for animation renders, frame will always be appended? So the wording would have to clarify that, maybe like @txo suggested where we use the word “Always”?

@txo

some sort of enum list with variables, could make it a more general solution, and also to have output variables be more discoverable?

Is that an operator that adds the variable syntax to the name?

@ManuelGrad

One possible solution could be never to allow multiple separate places that define output settings being active at the same time – once you enable the Compositor, the render properties output panel gets greyed out, its output will get disabled, and the functionality will be replaced by an equivalent comp setup with respective outputs.

See the task I linked above. But there were concerns with regards to that proposal, don’t remember the details right now. But let us discuss this separately since it probably wouldn’t affect the current redesign.

@ManuelGrad

but it looks like one of the most fundamental variables (framenumber) got removed at a late stage from the patch.

@txo

What? Really, it got scraped?

It will still be added, but it turned out a bit more complicated that anticipated, so it was delayed a bit.

@ManuelGrad

and finally having a frame number variable that can be used like this:

foo_{frame_number:####}_bar.exr

So the File Output node would never append a frame number, and the user can only use variable substitution to have it?

[ManuelGrad]

@OmarEmaraDev

So the File Output node would never append a frame number, and the user can only use variable substitution to have it?

I suppose so, yes. This is also how it works in other software (Nuke, Natron, …).

Or it can work similar to what happens for the output defined in the render properties output:

• if the user specifies a template/variable (currently ####) then it just uses that
• if the user renders multiple frames (animation render) that consists of more than 1 frame and no template/variable is defined, then do some hand holding and automatically insert a frame number before the file format (do render0001.exr, don’t do render.exr0001.exr)

[LudvikKoutny]

Yes, this exactly. The only valid reason to append frame numbers without users’ permission is under this combination of circumstances:

1. No defined frame variable in the output filename
2. Animation (not single frame) is being rendered

[txo]

@OmarEmaraDev

Is that an operator that adds the variable syntax to the name?

Yes, that’s right. I think it would provide a nice discoverable way to add the available syntax variables without having to poke inside the manual, or having to know it is even an option. Also, if it lists all variables, it wouldn’t be arbitrary, like with the frame toggle suggestion.

@OmarEmaraDev

So the File Output node would never append a frame number, and the user can only use variable substitution to have it?

@ManuelGrad

I suppose so, yes. This is also how it works in other software (Nuke, Natron, …).

Or it can work similar to what happens for the output defined in the render properties output:

• if the user specifies a template/variable (currently ####) then it just uses that
• if the user renders multiple frames (animation render) that consists of more than 1 frame and no template/variable is defined, then do some hand holding and automatically insert a frame number before the file format (do render0001.exr, don’t do render.exr0001.exr)

I agree with the second option that @ManuelGrad proposes. Have it append {frame_number:####} automatically only to animated sequences, and let users delete it manually if they want to (and even in that case, I would display a warning saying all frames will overwrite the same file, or something like that).

The way Nuke does it is very straightforward, but if you forget to set it right, you can end up easily rendering all the animation overwriting frame 001. That’s really bad. And in a production it wouldn’t happen, there’s tools for that. But for individual users, it would be a quite risky thing, I would be anxiously checking every time. And, honestly, how many times you would need to render multiple frames without specifying the frame number?

[thorn-neverwake]

@OmarEmaraDev

@thorn-neverwake Just to clarify, that option would only control single renders, but for animation renders, frame will always be appended? So the wording would have to clarify that, maybe like @txo suggested where we use the word “Always”?

I’m not sure you need “Always” as part of it… IE, Checked = Always, I would think.

But yes, only for single render cases. For image sequences (animations), i cannot think of a use case, one would lose frame saves one after the other (amusing, but probably not nice.)

[thorn-neverwake]

@OmarEmaraDev

I suppose I can add a warning in the node indeed.

Here’s the issue I’ve had with overwrites:

It’s common that I’ll start a new scene, by opening an existing and then turning it into something else.

Unfortunately, at some point in “redo scene” i hit Render to check something and completely forgot that i had a full compositing set up, which has active output nodes. Now I’ve just overwritten something that I rendered 2 weeks ago (and still need for a project.)

Now I have track down what I just ruined, open the original scene and render it again.

It’s happened a lot. So the choice becomes:

1. Just never forget, and ALWAYS check the compositor the moment I open every scene, before rendering. (Which is what I do now, if i don’t forget).

2. Always have “overwrite” disabled, until I finally want to render. Which risks rendering 300 files, none of which are saved, if I forget to turn it back on.

3. To prevent 300 renders not being saved, I have to go back to Step 1.

So, when i choose RENDER, if files are going to render, but not be saved - a warning of “FILES WILL NOT BE SAVED, continue?” popup, before rendering all of them - would be nice here.

[ChristophWerner]

Thank you for the information. Great to hear you’re starting to rework the output node in the compositor.
I haven’t read all the user comments above, so please forgive me if I repeat something.

Here are my proposals/wishes:

1. Proposal: As long as the user doesn’t add one or more hashes (#) to the filename, frame numbers should never be added for single frame renders. However, you should always add frame numbers when rendering animations, as you described.

2. Wish: Please add support for placeholders in filenames. I’m really missing the ability to use a placeholder for view layer names. Here are some examples of how placeholders could work in output filenames:

• <viewlayername> → saved as ViewLayer.png
• MyName<viewlayername>### → saved as MyNameViewLayer001.png
• MyName###<viewlayername> → saved as MyName001ViewLayer.png

4. Wish: Please add a checkbox to the image output node in the compositor to disable the image output function in the regular output properties. Most of the time, when I use the output node in the compositor, I don’t need the composite output to be saved as well.

5. Display a warning or notice in the regular output properties when an active (non-muted) output node is used in the compositor.

I support most of the ideas and solutions you’ve mentioned.

Best wishes,
Chris

[costavojik]

Hey so exciting seeing File Output node getting some love!

I have this “small” nodegroup i created in GN to demonstrate how a File Output would look if all settings were exposed. What differs here that the settings are per node and not per file like it is today, not sure how it’s possible to tackle each file getting his own setting in an elegant way and exposing settings in the node. Personally I think it might be even a good idea to simplify it a bit and make the settings per file output and then the user would create his own custom file output node with multiple file output nodes inside a “mega nodegroup” with the settings he wants to be adjustable exposed, for simple cases it will be an overkill but for bigger projects and productions it would be a life saver. Soon with bundles and closures it will make it just perfect!

Just throwing my 20 cents I think every change and improvement is welcomed anyways especially getting more variables:))

[LudvikKoutny]

Could be good to put Save as Render above Color Management, where setting it to False would simply hide the entire color management panel. When you’re not saving render, it means you intend to save raw data, which should never be color managed.