Denoise artifacts with Direct Glossy
Open, ConfirmedPublic


System Information
CentOS 7.4.1708
GNOME 3.22
i7-6850K (8 Threads)

Blender Version
Broken: 2.79 5bd8ac9abfa

When using the denoiser 'Direct Glossy' can cause artifacting. The intensity of the artifact may or may not be influenced (slightly) by SSS.

Exact steps for others to reproduce the error
Create and apply glossy material to object.
Add light(s)
Enable denoiser (with direct glossy)

Based on a (as simple as possible) attached .blend file with minimum amount of steps. Test with and without Direct Glossy. Uses default denoiser settings. If you disable both SSS on the Principled shader and the point light, the artifact shrinks.



Yeah, I am currently suffering from the same problem. I think it's mainly a problem with the very bright intensities of glossy reflections. At least in my case it doesn't need any SSS to produce the issue, just a rather reflective surface. I am facing this problem mostly with metals in scenes with bright lamps. I think the denoiser somehow tries compensate for the brightness differences between the glossy reflection and the much darker surrounding areas, and by overcompensating that brightness differences it makes the problematic areas black. Or something like that. No idea how to solve that but maybe as a workaround the denoiser could just keep the super bright highlights just white?
Here's the above file but without SSS and point lamp, but with a metal surface, still producing a black artefact.

Perhaps the denoising should work on log(glossy) or some other kind of remapping to bring the extreme values into a smaller range.

Dalai Felinto (dfelinto) triaged this task as Normal priority.Sep 18 2017, 3:24 PM

Changing priority to Normal, until @Lukas Stockner (lukasstockner97) confirms that this is a bug.

Perhaps the denoising should work on log(glossy) or some other kind of remapping to bring the extreme values into a smaller range.

I've just tried that, and while it works decently (I used no mapping between 0..1 and log(x)+1 above 1, since just using log(x) causes problems in really dark areas) it's really biased to do the regression in the remapped range and can make noisy images noticeably darker. In this case, the highlight ends up in the 1.7 range even though the original pixels are >40.
I guess making the NLM filter more robust to not overblur the highlight would be the better option here.

Generally, I don't really like any solutions that aren't exposure-invariant, mainly because they feel like a cheap band-aid fix instead of a proper solution...

But yeah, I would consider this a bug since highlights aren't that uncommon.

Dalai Felinto (dfelinto) raised the priority of this task from Normal to Confirmed.Wed, Sep 20, 3:55 PM