RayTracingDenoiser icon indicating copy to clipboard operation
RayTracingDenoiser copied to clipboard

Denoising on empty pixels yields random colors

Open nyorain opened this issue 5 months ago • 4 comments

v4.14.0-fixed, with REBLUR_DIFFUSE: We set viewZ to NRD_FP16_MAX for pixels without depth. And we put NRDs internal textures that are marked as transient into aliased memory. When moving the camera, we get random colors suddenly appearing at the horizon (i.e. near the infinite-distance pixels). If we either:

  • don't alias the internal textures
  • or set viewZ of the no-depth pixels to something within denoising range (with radiance=0),

we do not get this issue.

The random colors are more obvious during low-light settings. They look a lot like uninitialized memory accesses. Could it be that some internal textures are not written for out-of-range pixels but read later on thus yielding undefined content when the texture is aliased? I am sadly not allowed to share footage.

nyorain avatar Jul 21 '25 09:07 nyorain

Ah, I thought this might be a duplicate of #88 but even with ab875fe948cabf041fbf9982921d4f0e03118fe0 applied, this still happens. Maybe I have to update to the latest version.

nyorain avatar Jul 21 '25 12:07 nyorain

I think that current behavior is expected. It's done for performance reasons. The doc says:

[NRD] Most denoisers do not write into output pixels outside of CommonSettings::denoisingRange. A hack - if there are areas
(besides sky), which don't require denoising (for example, casting a specular ray only if roughness is less than some threshold),
providing viewZ > CommonSettings::denoisingRange in IN_VIEWZ texture for such pixels will effectively skip denoising.
Additionally, the data in such areas won't contribute to the final result.

I would say:

  • if you get color leaking from INF pixels (where viewZ > CommonSettings::denoisingRange) to "normal" pixels - it's a bug (last evidence of it was fixed in #88)
  • if you get "unexpected" colors on INF pixels, it's expected

But I don't see a problem to add a CMake compile-time switch clearing output on INF pixels to 0, if it's simpler for you.

dzhdanNV avatar Jul 23 '25 03:07 dzhdanNV

Unexpected colors on INF pixels themselves are not a problem but they are bleeding into non-INF pixels for me. I will update (so far I only cherry-picked the fix for #88) and then see if it's still an issue.

nyorain avatar Jul 25 '25 08:07 nyorain

Yes, please, try the latest. If bleeding there it's a bug.

dzhdanNV avatar Jul 25 '25 16:07 dzhdanNV