[..]
> 1600 was chosen since it fits into a series 50,100,200,400,800,1600
> very well.  Also, I figured that at some point someone would complain
> about a big include file.

interesting, thank you for the explanation. Does it mean that it's better to
choose a value for count which has a factor of 50 ?

> Note, if you have artifacts in a picture for which you want very high
> quality output, it is 99% certainty that the problem is a bug in the
> software (sorry) or the choice of other parameters, and <1% chance
> you really need more samples.

Some people were wondering why there were still some artifacts even for high
counts, if you've managed to fix it this is really great news ! Thank you !

> Generally you want to aim for the goal of having each final sample
> use an average of 20-ish old samples, but not from too far away.
> Typically the existing released code achieves an average of about 2.
> The number of rays in each old sample point is usually less significant
> to the overall smoothness achieved.

You mean the nearest_count should be 20 ? This seems quite a lot (the doc
says the default value is 5), isn't there a risk to smooth too much the
result ?

I don't know if it's worth investigating but I've come across a paper
(http://wfmh.org.pl/~thorgal/jatrac/papers/iccvg02-mskm-gradients.pdf)
suggesting to take more sample locations according to local lightning
distribution to improve Ward's original irradiance caching

M

Post a reply to this message