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.