Denoising causes NaN Pixels to turn into bigger black squares

[pokoy]

Corona 1.4
I let a render run overnight in DR mode with one additional DR machine. During the test it looked good but the final render showed a few small black areas and when inspecting the pixel values the tool displayed -nan(ind) in the original RGB values. They would've been easy to retouch in post, however after stopping the render the small areas turned into much bigger black squares which display 0/0/0 as mapped RGB values. So it ended up to be completely unusable, unfortunately I only have the state after the rendering was stopped, image is attached. When zoomed in, you can see jagged borders two sides, maybe it's useful information. Adaptivity was on, denoising too.

Is this caused by denoising? Why would a NaN pixel turn into a square?

[pokoy]

I was able to reproduce it and it happens during the Denoising calculation stage.

So apparently denoiser works in square chunks (52x52 pixels it seems) and a single NaN pixel will cause the whole chunk to turn black, making it impossible to retouch in post. This should be fixed in a way so NaN pixels are not taken into consideration or better filled with an average color based on the neighbor pixels before denoising does its job.

[FrostKiwi]

Not a number Pixels should never ever happen in the first place. It makes no sense to bandaid a rare occurrence of the renderer delivering badly formatted floats.
Since you can recreate this, do post it on Mantis (https://corona-renderer.com/bugs) with instructions or scene file to recreate.
Nan pixels being returned is the renderer failing at the very thing it was suppsed to produce... Pixels :D  Such a heavy bug has top priority in fixing.

[pokoy]

Not a number Pixels should never ever happen in the first place. It makes no sense to bandaid a rare occurrence of the renderer delivering badly formatted floats.
Since you can recreate this, do post it on Mantis (https://corona-renderer.com/bugs) with instructions or scene file to recreate.
Nan pixels being returned is the renderer failing at the very thing it was suppsed to produce... Pixels :D  Such a heavy bug has top priority in fixing.

While I agree with you I'd rather like to see a patch kind of fix since the possibility of a NaN pixel will remain.

[FrostKiwi]

Ultimately it is the dev's decision, but NaN should never ever happen. If something is unsupported it should return Red, but a NaN error is a fringe condition nobody checked and is not picked up by any exeption in the code, that flags it as unsupported. A major major fault.

[Ondra]

Fixing NaNs is easy, can I have the scene?

[pokoy]

I'd like to see if I can strip the materials/textures from it and if it still produces NaNs. But generally, yes, it's just my personal stuff.
Is there a way for a private upload?

[Ondra]

Of course, same as always: https://corona-renderer.com/upload/

[pokoy]

With simple grey material override there are no NaN pixels. I have two other suspects and want to try these first, if this works, fine, if not I'll supply the scene. If you want I can supply it anyways but with some more tests I may have some hints on what causes this.

As for the original question, shouldn't Denoising be improved to handle cases like this, too?

[Ondra]

no, its better to just prevent all NaNs ;)

[pokoy]

So I just tried to reproduce it - it was reproducible before - and it's not showing any NaNs anymore. The only thing I did in between was to uninstall Corona (to check how 2017 behaves because of the comma/dot issue) and install it again... scratching my head right now, not sure why this can affect rendering.

[Ondra]

ok, if you ever come across NaNs again, please report it again

[alexyork]

One thing to check - did you clear the frame buffer for each test render where NANs were showing? I've had this before. No matter what you change in the scene the NAN(s) will remain until you clear the buffer. I now always check Clear buffer before rendering for all renders. For me it's peace of mind...

[pokoy]

No, it was reproducible with fresh max session.
Thanks for the pointer, will keep that in mind.