not sure if this post should be here or in Blender Dev section, but its tighly related to rendering so I put it here.
Right now when I select a non multilayer file format in the output properties (png, jpeg, exr, etc.), I only obtain a single image per frame on disk: the combined image, from one of the view layer (the last one from the dropdown list of the image editor that appear when I press “Render animation”). All other images are in memory, visible from the image editor, but not written on disk.
Is there any option in Blender to write all rendered images on disk ?
If not I will implement this and I’m thinking of adding a checkbox to enable this in the Output properties panel, what do you think ?
Also I know I can do that with FileOutput nodes but due to limitations with EXR metadata related to cryptomatte (see #64953 - Cryptomatte - File Output node is messing up the multilayer exr (metadata), so blender cryptomattes cannot be read properly in external compositors - blender - Blender Projects) we are planning to use the main output of Blender.
There’s no option for this currently.
It would be useful to support, but I expect it will require a fair amount of work. To ensure things work well with the compositor, Save Buffers option, animation denoising, compositing, and so on.
There used to be more requests about this, but most software tends to support multilayer EXR well now so the advantages are not so obvious.
Yeah what I’m talking about is mainly to offer more workflow possibilities. However our artists seem to think that working with one image sequence for each pass is more flexible (despite the fact they were all for multilayer EXRs before experimenting a bit more haha).
Thanks for your answer, I will look into that and come back for questions here if its more complicated than expected.
There is a problem with working with Multilayer EXRs, sometimes you reach a point that you may only need one or two layers for an specific part of the shot, or when you are working in an specific part of the shot, but the software you use has to deal with 500Mb per frame, when you would easliy need just 50Mb per frame in that case.
So Multilayer EXR is good, but there are many times that it’s not optimal for production.
With that said, I think that fixing the metadata writing with the file output node could be enough to solve this.
If performance is an issue, it would be good to look at writing multi-part OpenEXR files. In OpenEXR 2.0 files can be written so that you can more quickly read individual render layers and passes.
We’re probably not taking advantage of that (but I haven’t checked the code so I might be wrong).
That solved the problem as long as you have the files locally, but if you work over the network, like many studios big and small do, the file size it’s still a problem, you need to transfer those 500Mb of file before the optimizations can come into play AFAIK
Anyways, I think in general following the KIS norm is the best course of action, so if we try to keep it simple, making the file output capable of transferring the metadata, and having an option in that node that makes use of the same output path as the main output path (for network rendering and/or interoperabiltiy between OS’s, something that is not currently possible) could be the best idea, less work, still solves the problem without creating a new one.
If we think in OpenEXR 2.0 (which I think we don’t use it, I’m not sure) we could also think in deep compositing and other things, and then the wheel starts spinnig and will never stop hahaha
Network file systems generally do not require transferring entire files.
We already use OpenEXR 2.x and multi-part files for stereo rendering.
Interesting, regarding the network file system could be interesting to test some exr’s to see the performance benefit of those exr’s and compare to our current outputs.
If you know of some example files tell me please