LuxCoreRender Forums

B.Y.O.B. wrote: ↑Mon Nov 26, 2018 2:24 pm

lacilaci wrote: ↑Mon Nov 26, 2018 2:20 pm I'm recently also observing that a lot of low light noise can be avoided by using much higher path depth for diffuse and glossy. Does it really help much to have it by default at 4? I find that too low and hard to reach areas get a ton of noise

Might have something to do with russian roulette depth (which is not exposed in the addon).
https://wiki.luxcorerender.org/LuxCore_ ... PATHCPU.22
Maybe we could optimize this - Dade, can you help?

@lacilaci, could you post an example scene that shows this behaviour?

Can't now and this whole week is pretty busy for me. But I noticed this in every scene.
Use high adaptivity to exaggerate the effect = 0.95 and lower warmup and test step to 8, then compare with default 64 for each. I've seen this in multiple builds, curently in linux, but it shouldn't matter.
If you can't reproduce I'll put something together on the weekend maybe. (maybe related, I also always use heavy clamping - maybe affects this issue)

EDIT: I just realized, if I give more room between test step samples, then adaptivity has lesser effect on the image so I guess it makes sense that low warmup and test step samples introduce more noise...

lacilaci wrote: ↑Mon Nov 26, 2018 2:20 pm Also, low values for warmup and step samples give me noisy result while renderer ends soon telling me that it converged at 100% How can it consider rendering done when it's noisy?

It depends on the threshold noise you selected for the convergence test, indeed higher is the threshold and higher is the noise of a 100% "converged" result (i.e. where "converged" means all the noise is under the selected threshold).

B.Y.O.B. wrote: ↑Mon Nov 26, 2018 1:08 pm

FarbigeWelt wrote: ↑Mon Nov 26, 2018 12:45 pm whereas single pixel uneighboured fireflies can be easy replaced by surrounding colors.

Yes, but once they begin clumping together it's getting messy.

Indeed, this is what usually happens.

A generic question, noise related:
How shall an algorithm be able to determine noise if the algorithm is not able to realize what it is looking at?

Without understanding what picture actually shows, noise is not to be distinguished from any patterned content viewd from steep angles or objects with fine glossy color shades.

I think there should be some exposure range in which the noise is possible to detect and pixels outside that range should be ignored. This way you could setup visible noise to be evaluated only... Maybe..?

lacilaci wrote: ↑Mon Nov 26, 2018 6:08 pm I think there should be some exposure range in which the noise is possible to detect and pixels outside that range should be ignored. This way you could setup visible noise to be evaluated only... Maybe..?

Sounds good and is to some part feasible if smoothing is allowed to some degree. This is actually what I‘m trying to get reliable with definable smoothing factor in my simulations. Feasible but not as easy to achieve as first thought. I hope to get acceptable results soon to demonstrate how.

I think you should do some research on existing algorithms in this area, just so you don't reinvent the wheel and waste your time

B.Y.O.B. wrote: ↑Mon Nov 26, 2018 8:48 pm I think you should do some research on existing algorithms in this area, just so you don't reinvent the wheel and waste your time

You are right. This is surely a better way, there must be plenty of solutions available 'cause of an obvious problem. But, it was actually much fun for me so far and one has to stand up before walking and running is possible

Before I start reading some papers, here some impressions of a 20*20 image input with easy patterns and two gradients. As previously mentioned the matter gets very complex for further steps and the first and easiest step, limiting colors by choosing a similar but more often used color, is a rather good one.