Denoising

Table Of Contents

• Denoising
• Introduction
• Altus
• OptiX and OIDN
• Animation Considerations

 

 

Introduction

Rendering effects like depth of field, motion blur, global illumination, area lighting and others require the renderer to shoot multiple rays into the scene. If a low number of rays ("samples") are shot, the final result can appear noisy ('grainy'). The typical solution to this is increasing the number of samples (as explained here), but that means longer render times.

An alternative (and faster) solution is to use denoising instead. "Denoising" refers to a rendering technique that removes noise from an image. The process can be fast or can take a good few seconds. In both cases, though, it should take less time than Redshift would need to render the scene without noise by increasing sample counts.

Redshift supports three different denoisers: Innobright's Altus , NVidia's OptiX AI denoiser and Intel's Open Image Denoise (OIDN)

Altus uses a traditional and production-proven techniques to achieve its denoising effect. On the other hand, OptiX and OIDN use deep learning algorithms that have been trained with tens of thousands of images.

Each of these denoising solutions have pros and cons:

Altus pros and cons

Uses production-proven algorithms so results can be more predictable

Available with all hardware

Denoising takes several seconds to compute so it's not possible to use in an interactive fashion

OptiX pros and cons

Is very fast and can be used in interactive rendering while editing the scene

Sometimes it can't detect noise because it hasn't been trained with that particular case, so it has trouble cleaning it

Only available with Nvidia hardware

 

OIDN pros and cons

Is fast and can be used in interactive rendering while editing the scene

Available with all hardware

Sometimes it can't detect noise because it hasn't been trained with that particular case, so it has trouble cleaning it

It should be noted that denoising is not a silver bullet! If the rendered image is excessively noisy, denoising can fail in many different ways:

• The denoise might fail to denoise the image to a sufficient degree (i.e. noise will still be present after denoising)
• It might 'oversmooth' certain parts of the image and lose considerable amounts of detail, especially in textures or small geometry details
• It might produce weird visual artifacts, in some cases these might look like brush paintstrokes.
• In animations, the noise might appear as ugly 'flickering splotches' which could be more visually distracting that the original noise!

For these reasons, we recommend that denoising is primarily used only to clean "the last few percent" of noise. In other words, you should still tune the settings for an 'okay' level of noise and then use denoising to make the frame perfect. This workflow is particularly important to follow when rendering animations.

Altus

The Altus denoiser options can be found in Redshift's Sampling tab.

To enable denoising with Altus simply select "Altus Single Pass" or "Altus Dual Pass" for the denoise engine and then do bucket rendering (Altus does not work in progressive!) using the Render View.

"Altus Single Pass" means that the frame will be rendered once and then Altus will execute denoising. "Altus Dual Pass" means that the frame will be rendered twice before denoising. We recommend using "Altus Single Pass" if you are a new Altus user.

In the early days of the Altus-Redshift integration, there was no Single Pass mode available in Altus so the only option available to users was the Dual Pass approach. Altus required two separate rendered frames to determine where the noise is. The drawback of this approach is that the frame takes twice as long to render because it gets rendered two times! Some users got around this by tweaking their unified sampling settings and increasing the error threshold right before denoising. This lowered render times but also meant that both frames would be noisier - but that was okay because Altus would clean the noise.

At a later point in the Altus-Redshift integration, Innobright introduced their Single Pass technique which can determine per-pixel noise in a single render pass. This approach is much more natural as it doesn't double the frame time and doesn't involve the user having to do any tricks like the above tweaking of the unified sampling settings.

Altus can achieve more accurate results with the use of additional Redshift AOVs. When "Automatically Create AOVs" is enabled, Redshift will automatically add any AOVs that Altus needs to achieve its denoising results. Disabling that option means that the user will need to manually add the necessary AOVs. The AOVs used by Altus are: Diffuse Albedo, World Position and Bumped Normal

While Redshift is rendering, it generates some additional images ("buffers") which are essential for the denoising process. These buffers are normally hidden from Redshift's Render View but if you check "Show additional buffers in RenderView", those buffers will be viewable in the Render View's AOV list. This can be sometimes useful when diagnosing denoising.

The kc1, kc2, kc4 and kf settings allow the user to control the quality and "denoising strength" of Altus.

• kc1 controls how much high-frequency detail will be retained (i.e. sharp image features)
• kc2 controls how much medium-frequency detail will be retained
• kc4 controls how much low-frequency detail will be retained (i.e. chunky image features)

Lower kc values will retain more detail while higher values will make the denoising stronger. I.e. it will produce smoother results but it might lose details

The kf parameter controls AOV influence. I.e. determines how much AOVs affect the denoising results. Smaller values make the AOVs affect the denoising result more. So, for example, if you have a bump map and you see Altus smoothing the lighting on it too much, lowering the kf value will help. However this will also constrain the denoiser which means that, if the image is very noisy, it will not be able to denoise it too much around the "bumpy areas" (in this example).

After the frame has rendered and Altus has denoised it, you can toggle it on or off (to better see ibahahahts effect) in the Render View by pressing the  button of the Render View.

OptiX and OIDN

To enable denoising with Optix or OIDN, pick set one as the denoise engine and render in progressive or bucket rendering mode with the Render View.

These denoise engines can achieve more accurate results with the use of additional AOVs. When "Automatically Create AOVs" is enabled, Redshift will add any AOVs that OptiX and OIDN need to achieve their best denoising results. With this option disabled you will need to manually add the necessary AOVs instead. The required AOVs are: Diffuse Albedo and Bump Normals

While Redshift is rendering, it generates additional images ("buffers") which are essential to the denoising process. These buffers are normally hidden from  Redshift's Render View but if you check "Show additional buffers in RenderView", those buffers will be viewable in the Render View's AOV list. This can be sometimes useful when diagnosing denoising.

OptiX and OIDN are fast denoisers however, even with their speed, they can still "steal" a percentage of the frame's total render time. That's especially true when rendering high resolution images in bucket mode because Redshift denoises the entire frame after each bucket. For this reason, Redshift supports a separate "denoise overhead" setting for bucket and progressive rendering. These settings control how often OptiX and OIDN denoising is executed. A setting of 10 means "execute denoising as often as needed but ensure that it doesn't take more than 10% of the entire frame time". A setting of 100 means "execute it after every single pass (in progress) or bucket (in bucket rendering)". A setting of zero tells Redshift that it should only denoise once at the end of the render which is the best value for denoising high resolution images.

The benefit of lower "overhead" settings is that denoising will take less time overall. The drawback is that because denoising only gets executed every few passes (in progressive mode) or every few buckets (in bucket rendering), some "visual lag" might be noticeable. This is the main reason why the default denoise overhead is 10% for bucket rendering (where lag matters less than rendering performance) and 100% for progressive rendering (where the opposite is true).

After the frame has rendered and it has been denoised, you can toggle between the noisy and denoised versions of the frame in the Render View by pressing the  button to compare the differences.

Animation Considerations