Oh, I did not know that OIDN was a deep learning based denoising filter. That must be the reason why I did not find similar configurations to other denoisers like Strength, radius, etc.
Exactly.
I though some more about it and remembered that they are not directly dealing with HDR, but instead use tone mapping and denoise the tone mapped images. This might brighten this whole section enough that it denoises it in this sort of way. Though thatâs just a speculation.
If thatâs true, it likely indicate a broader issue in their approach when dealing with HDR and fireflies. But again, that is just a speculation.
That is quite unfortunate, as the reflections in that same blue ball appeared to have come out with better quality. Even with the despeckle node, a few of the fireflies were not processed.
Now Stefen needs to figure out if there is something he can do on his end to resolve such failures, as it could mean the implementation having to wait again until Intel resolves it.
On that last part, now we can understand one of the strengths of Blender having its own denoising code, Lukas and Brecht can resolve issues or commit improvements right away when they have time.
Another test set with scene showing fireflies (OIDN v0.8.1). Original scene is from here (expired link):
https://blenderartists.org/t/experimental-2-77-cycles-denoising-build/664697/461
Re uploaded here (I hope it is allowed):
Vray_vs_Cycles_vs_Maxwell.7z (4.6 MB)
Test with 200 samples.
Original:
Original, Clamp Indirect Light=10
Blender Denoiser:
Blender Denoiser, Clamp Indirect Light=10
OIDN:
OIDN, Clamp Indirect Light=10:
OIDN result seems cleaner, without spots/patches and it shows more detail. But comparing Indirect Clamp vs. No Clamp, OIDN seems to misunderstand fireflies with lighting (*), so images clamp vs no clamp have differences in brightness/lighting with OIDN. Anyway in a scene like this youâll want Clamp Indirect Light, in fact Clamp Indirect value is â10â by default in Blender 2.8.
Edit:
(*) Wrong! See here:
https://blenderartists.org/t/cycles-development-updates/1110067/999
2 Likes
Unfortunately, the bricks texture in the interior portion seem muddy in spots.
This tricky thing that is machine learning, an algorithm using it can give you excellent results in one situation and terrible results in another. It shows off how naive the algorithms are unless specifically guided by training data and/or pass information. This is the same reason why Nvidiaâs much hyped DLSS algorithm is underwhelming in its first go around in game titles.
I think that if maintenance for developers is not very expensive, OIDN should definitely be included in master branch. User then decides if he/she uses or does not use the filter. OIDN is giving better and faster results than any other node group for denoise that I have tried before in compositor.
Fireflies are caused by caustics in this case. And the sun energy isnât even up there. And the main bounce surface isnât even glossy. Bounced sunlight at proper values will not only cause fireflies, but contribute heavily towards adding noise - especially in scenes like this where nearly all light is indirect. The scene also have tons of other proplems.
Which is the correct thing to do. Fireflies are lighting. Clamping them removes energy from the scene.
1 Like
Oh, what you say sounds logical. So Blender denoiser is the one doing the wrong thing? I ask this because when comparing OIDN (No Clamp) with Blender denoiser results, OIDN result is brighter.
So if I render the scene (No Clamp) with a very high sample rate that makes fireflies disappear, I guess what you mean is that the result obtained will be more like OIDN (No Clamp) result?
EDIT:
Ok, I know. You do the test yourself!
Here a portion of the render to 30000 samples (sorry, not good hardware here and I need to do other things on the PC). Only to compare lighting, no noise level. No Clamp lights on any of them.
Original 30000 samples
OIDN 30000 samples
OIDN 200 samples
Blender denoiser 200 samples
So in fact, OIDN at 200 samples was the one that most resembled in terms of lighting to original render at very high sample rate?
I started to be afraid of Neural Networks/deep learning systems 
And thinking about it better, I guess it does not happen that Blender denoiser is wrong. I suppose that by design with this kind of filters is close to the best that can be achieved in this regard at such a low sample rate. I suppose that for this reason we are always reminded that Blender denoiser is mainly to eliminate residual noise at high sample values.
Hi Stefan! I would like to understand better about fireflies. It make sense that they are lighting information, but isnât a firefly a spot where the engine had trouble converging to the right result and so it represent a value that is quite âout of scaleâ? If so, shouldnât the fact that the values for such pixel are completely off-scale be taken into account by the denoiser to âaverageâ the value of such pixel based on the neighbours?
I might have written some stuff which is completely not true, thatâs why I am asking you as I would like to understand better the firefly and relative denoising process 
Fireflies should be taken into account, yes.
As an example: If the brightness of the scene should be 1, you might have 99.9% of pixels with value 0.95 and 0.1% of pixels with value ~50. In that case, the latter pixels are fireflies, but if you just ignore them and denoise the remainder, the image will be 5% too dark.
Side note: The same darkening happens when you use clamping.
Also, @YAFU is correct, the current Cycles denoiser just ignores them, which is incorrect and darkens the scene. Some papers have suggestions on how to split the fireflies into a separate pass and spread their brightness over the image, but thatâs very complex to get right so I didnât implement it (yet) since it didnât seem worth the effort: As you mentioned, the Cycles denoiser was designed to clean up already-decent renders, so if you have that many fireflies you should probably look into getting rid of them in the first place.
2 Likes
Thanks for the answer Lukas! So basically in both OIDN and the blender denoiser thereâs an approximation, the first approximating taking into account a pixel with a value that is exessively high, the latter doing the opposite?
When you say about the 0.1% of the pixels having a value of ~50, isnât that value an error?
I probably lack the knowledge about path tracing to fully understand this, but it seems to me both method are not fully correct.
I donât really know how OIDN works internally. The Cycles denoiser just discards fireflies, so it underestimates the brightness.
Also, fireflies are not really errors, just an unfortunate result of how path tracing works. For example, letâs say you have a room lit from a sun outside of a glass window (assume real glass, not the tricks that are generally used for windows). Shadow rays are blocked by the glass, so Cycles only hits the sun if it randomly bounces from the floor into a direction that, after two refractions, ends up hitting the sun. The probability for that is extremely small, so the resulting value must be extremely high to produce the correct result on average.
Generally, fireflies mean that the sampling strategies of the render engine (e.g. direct light sampling or importance sampling of the BSDF) failed to account for a high-intensity case.
1 Like
thanks! So yeah, for sure the internal, ignoring the fireflies approximate badly. Either way, it looks like a very âcomplexâ situation. We use something that, if I am not mistaken is always an approximation (the denoiser), starting from a value which was generated as a result of some badly done calculations (the firefly). I guess expecting to have ideal results there is quite optimistic 
I am not obssessed with extreme accuracy, so I just like the fact that the OIDN produce much less bloaches. Then if it slighly change the lighting in some point, I donât see it as a huge issue. Not as big as the bloaches anyway.
Side note, Iâm currently working on something that should hopefully reduce the blotches drastically while preserving overall qualify and only adding ~40% to the denoising time. Details hopefully soon - Iâve been looking into it for a while, but had absolutely no time for the last 1-2 months, but now I should have time to continue working on that, baking and UDIM.
17 Likes
thatâs great to hear! By the way, take all the time is needed for UDIM and baking, thatâs definitely something I am looking forward too!
Changing a bit subject, but still cycles related: can the work regarding baking help with bringing custom AOVs to cycles? By AOVs I mean the ability to create arbitrary outputs in a shader node tree to have as render passes for compositing purposes. I think you perfectly know what they are, I am just not sure 100% by saying AOV I am referring exactly to the thing I want
1 Like
The denoiser is already horribly slow 
cant imagine it being 40% slower oh lawd
Try something like this in the nodes. It has some problems in some cases but overall it works significantly better than stock OIDN (Noise wise)
you can probably get away with using only 3 denoise nodes after the adds. It behaves weird on transparent objects like glass and transparency but still dose a decent job with the cleanest images you have ever seen 
Oh yeah plug the denoising normal in. I forgot to do that in this screenshot
Without crazy nodes
With crazy nodes
2 Likes
This explains A LOT!
I had problems with RGBA textures (especially DDS) containing different information (roughness, masks, etc) many times.
And every time I was asking myself: Why doesnât this work?
But it didnât - so I assumed I was doing something wrong.
My solution was usually convert DDS to PNG and/or split off the alpha channel into a separate image, just like you did.
Now I finally know what was going on! This is really a relief for me!
PS: I hope this gets fixed REAL soonâŚ