Let's Improve the Denoiser for Animation in Production Use

[Joelaff]

Chaos has done a nice job getting denoising working for animations. Let's try to improve the denoiser process for actual production use in animation.

While usable as-is, there are a number of small things that would really help smooth things out for a fluid flow in production.


Please start a separate thread if you would like to add requests for improving the denoiser for stills.


Improvement to vdenoise for production animation use:

• Ability to read/input render elements from individual channel file sequences (e.g. RGBA and normals, noiselevel, etc. in separate files in the input)-- and in separate folders. It should automatically look for the correct channels names in the same folder, or in the default folders created by the "Separate render channels" "Separate Folders" options in the VFB settings of VRay. Ideally, these separate channel (elements) file locations should also be able to be specified on the command line, but the auto-search is more important because these files will generally be consistent, as they are written by VRay.
• Ability to remove all EXR channels that were NOT denoised from the output file-- Thus we still have the source files, and any denoised channels on disk. No duplication of non-denoised data.
• Ability to split render element channels into separate EXR sequences (and in separate folders) for output... Including the ability to read a monolithic EXR and output separate channels OR read separate channels and output separate channels.
• Ability to have consistent output filenames regardless of whether the GPU was used for processing or the CPU. Right now I get "ocl" added to any output made using the GPU, but output made with fallback to CPU does not include this string. So this makes the image sequence worthless (or have to be renamed with a script at least). This should default OFF--not useful as is. Who cares which method was used? Are they not deterministically identical?
• All of these options get command line switches so this can all be done through render controllers like deadline. These changes should also be in the GUI if possible for those who prefer that method. No need to make the GUI fancy, just functional.

Thanks in advance.

[Joelaff]

Please see the initial posting for the point of this thread, but there is a bug in vdenoise where there is a specific error that can occur when denoising where the operation fails, but still returns a 0 (zero) error code, and is thus ignored by render controllers:

The reported error is:

warning: VDenoise: Cannot fit any region in memory!

The result is that vdenoise writes an UNdenoised image to the output.

2022-12-26 00:51:59: 0: STDOUT: Denoising 24 render elements based on RGB color

2022-12-26 00:51:59: 0: STDOUT: warning: VDenoise: Cannot fit any region in memory!

2022-12-26 00:51:59: 0: STDOUT: Denoising 24 render elements based on RGB color... done

2022-12-26 00:52:00: 0: STDOUT: Denoising complete in 14.56 s

2022-12-26 00:52:00: 0: STDOUT: Writing image file "G:/DenoiseTest/Can/Test2/Can_denoised_ocl.1075.vrimg"

2022-12-26 00:52:37: 0: STDOUT: File written successfully.

2022-12-26 00:52:37: 0: INFO: Process exit code: 0
​

Obviously, this a a BAD THING.

In this case it was on a machine with an older 750 video card, which was not capable enough for the task.

[Joelaff]

Any thoughts on this topic? Would be great to get this more production friendly.

As is I modified deadline to remove the “ocl” from files so both cpu and gpu can be mixed.

Our farm is Cpu with only a few nodes having decent GPUs. However, even though slower we can have a few basic machines without vray licenses running that can handle most of the denoising via cpu because the frame render times are so much higher than denoising times.

[vlado]

Thanks for the suggestions and for the bug report- will look into it. In the meantime I'm not sure if it is an option to tell vdenoise to always run on the CPU (using the -useCPU=1 option).

Best regards,
Vlado

[Joelaff]

Thanks, vlado. Yes, that is an option, but of course it is nice to use the GPU if it is available. It's one of those little catch-22 things. If a single machine with a decent GPU becomes available it can denoise much faster (of course you still have the I/O, and multiple slower machines can be faster if the network/fileserver can handle it).

[Joelaff]

Please see the initial posting for the point of this thread, but there is a bug in vdenoise where there is a specific error that can occur when denoising where the operation fails, but still returns a 0 (zero) error code, and is thus ignored by render controllers:

The reported error is:

warning: VDenoise: Cannot fit any region in memory!

The result is that vdenoise writes an UNdenoised image to the output.

2022-12-26 00:51:59: 0: STDOUT: Denoising 24 render elements based on RGB color

2022-12-26 00:51:59: 0: STDOUT: warning: VDenoise: Cannot fit any region in memory!

2022-12-26 00:51:59: 0: STDOUT: Denoising 24 render elements based on RGB color... done

2022-12-26 00:52:00: 0: STDOUT: Denoising complete in 14.56 s

2022-12-26 00:52:00: 0: STDOUT: Writing image file "G:/DenoiseTest/Can/Test2/Can_denoised_ocl.1075.vrimg"

2022-12-26 00:52:37: 0: STDOUT: File written successfully.

2022-12-26 00:52:37: 0: INFO: Process exit code: 0
​

Obviously, this a a BAD THING.

In this case it was on a machine with an older 750 video card, which was not capable enough for the task.

I wondered if we couldn't get the incorrect return code fixed on this, even if we can't get all the other things addressed. This is leading to some frames that are not denoised ending up in the final output because Deadline has no idea vdenoise failed because the return code is zero when it definitely should not be.

Thanks.