OTOY Forums

Is this normal? I was under the impression that the Denoiser is some kind of magic function, that smoothens the image AFTER it has been rendered (therefore it shouldn't increase the render times)



If it's indeed normal, then I'll just accept that one has to pay with some render time to get the denoised result in the Octane4.

Thanks in advance for any kind of response!

Yes, this is normal. Nothing happens instantaneously, and the denoiser is a pretty sophisticated tool. Depending on your hardware, it could easily take a few seconds. Yes, it happens after the primary render, but it's still part of the overall render process, like any of the other post effects. In this case, you are rendering a pretty fast image to begin with, so adding a few seconds seems like a lot. However, think about it a little differently.

Instead of comparing
without denoiser to with denoiser
campare
with denoiser to without denoiser and enough additional samples to reduce the noise as well as the denoiser does

So instead of comparing 0:23 to 0:30, you might be looking at 0:30 to 1:15 or more, so saving a good 45 seconds. It depends on your scene and tolerance for noise.

With smaller, faster rendering frames, the denoiser doesn't have as much impact, but if you are rendering 10:00 frames without the denoiser, and you can drop that down to 3:00 with, it's a huge difference. Or say you're rending a high res product shot, you might go from an hour per render down to fifteen or twenty minutes.

Okay, I understand what you're saying and it makes perfect sense. I accept the premise that you pay with some time AFTER the render has been finished to get the denoised result plus it's WAY faster to get quality, noise-less result.

Why does octane does this then?



I've noticed this issue couple months back and since that day I've been wondering why denoiser slows down the render speed.

Hurricane046 wrote:I've noticed this issue couple months back and since that day I've been wondering why denoiser slows down the render speed.

That's pretty weird. I haven't seen that before. It really should just tack a few seconds on to the end of the render, as long as you have the "on completion" option enabled, which you do, and you've certainly got plenty of free VRAM, so it's not a memory issue. I see you are using V4, but I don't remember it being a problem with that. Can you upload an example file that shows that behavior?

Okay, this is the test scene (it's ready to go, just hit render)

MyAirBridge https://mab.to/fYRh1ekqL
Wetransfer https://we.tl/t-ikFw3RfJ18

Yes this is a strange case, rendering is going slower with AI denoiser. I'll call the core team to investigate it.

The denoiser doesn't operate only on the final rendered image - it uses various other render passes as input too. When denoising is enabled, Octane needs to render these additional passes behind the scenes during the render to be used as input to the denoiser. That's the reason for the speed difference. Usually the difference should be reasonably minor but this depends on the details of the scene - in some scenes the additional passes may account for a significant portion of render time. In the example scene provided the impact is quite large, hopefully this is not typical, but yes, in general "one has to pay with some render time to get the denoised result" is correct.

karu wrote:The denoiser doesn't operate only on the final rendered image - it uses various other render passes as input too. When denoising is enabled, Octane needs to render these additional passes behind the scenes during the render to be used as input to the denoiser. That's the reason for the speed difference. Usually the difference should be reasonably minor but this depends on the details of the scene - in some scenes the additional passes may account for a significant portion of render time. In the example scene provided the impact is quite large, hopefully this is not typical, but yes, in general "one has to pay with some render time to get the denoised result" is correct.

Karu, I realize that to some extent, this is the Otoy's Secret De-noising Sauce we're talking about, but could you be a little more specific about which other passes are used, and what might slow them down, for our own troubleshooting and optimization? I had assumed the denoiser was just using the final plus the noise info pass used with Adaptive Sampling, but from what you've said, that does not seem to be the case.

I've tried stripping this example scene down to what seems very basic, (single light, no motion blur, no depth of field, no environment, no post processing, default camera, very basic materials, etc.) and the oddly extended time for denoising persists. There's nothing obvious that jumps out at me as needing extra render horsepower for de-nosing compared to any of a hundred other scenes I've worked on over the last few years.

Interestingly, by switching over from Path Tracing to Direct Lighting, and increasing the samples to get the same base non-denoising render time as Path Tracing, then turning on denoising, the denoising only adds a few seconds to the Direct Lighting, as I would normally expect. So the problem is specifically something about the way Path Tracing handles denoising.

Any additional insight into what's actually going on would be appreciated.

frankmci wrote:

karu wrote:The denoiser doesn't operate only on the final rendered image - it uses various other render passes as input too. When denoising is enabled, Octane needs to render these additional passes behind the scenes during the render to be used as input to the denoiser. That's the reason for the speed difference. Usually the difference should be reasonably minor but this depends on the details of the scene - in some scenes the additional passes may account for a significant portion of render time. In the example scene provided the impact is quite large, hopefully this is not typical, but yes, in general "one has to pay with some render time to get the denoised result" is correct.

Karu, I realize that to some extent, this is the Otoy's Secret De-noising Sauce we're talking about, but could you be a little more specific about which other passes are used, and what might slow them down, for our own troubleshooting and optimization? I had assumed the denoiser was just using the final plus the noise info pass used with Adaptive Sampling, but from what you've said, that does not seem to be the case.

I've tried stripping this example scene down to what seems very basic, (single light, no motion blur, no depth of field, no environment, no post processing, default camera, very basic materials, etc.) and the oddly extended time for denoising persists. There's nothing obvious that jumps out at me as needing extra render horsepower for de-nosing compared to any of a hundred other scenes I've worked on over the last few years.

Interestingly, by switching over from Path Tracing to Direct Lighting, and increasing the samples to get the same base non-denoising render time as Path Tracing, then turning on denoising, the denoising only adds a few seconds to the Direct Lighting, as I would normally expect. So the problem is specifically something about the way Path Tracing handles denoising.

Any additional insight into what's actually going on would be appreciated.

There is nothing special about it. The denoiser needs more data than just the main pass. That data is not visible but still calculated. Generating this additional data requires extra cycles and memory. And all that additional data needs to be stored (which takes time).

The problem with the scene you gave to Karl was that you had "Max. tile samples" set to 1. What this means is that you render only one sample per pixel before the render tile is downloaded to the host and then added to the render film. Since the rendering with the denoiser enabled, produces tons more data than with the denoiser disabled, a lot more data needs to be accumulated in the render film on the host. Usually that's not much of an issue, if you have render and accumulate a reasonable amount of samples on the device before you fetch it and then add it to the render film, so the CPU can keep up with the GPU. But setting "Max. tile samples" to 1 means that there is no accumulation happening on the device and thus a lot more data needs to be copied and accumulated. -> The GPU is waiting for the host to do all that.

TL;DR: As a rule of thumb, keep the maximum tile samples at about twice the value as the parallel samples and you should be good.

Ah-ha! Thanks, abstrax.

That wasn't even my file, it's Hurricane046's, but I was trying to figure out what was going on with it, for my own understanding. That's a very useful insight about how Max Tiles works, though.

Sure enough, turning Max tiles back up to the default of 32 or higher completely eliminates the odd behavior. I totally missed that he had set it to 1. If anything, I usually crank both Parallel and Max Tiles up if I've got the memory for it.

Much obliged, sir!