Adaptive Manifolds for Real-Time High-Dimensional Filtering
http://www.inf.ufrgs.br/~eslgastal/AdaptiveManifolds/
Real-time noise filtering.
TS1234,
It is quite naive of you to just compare two renders and deduce that it must be the reconstruction filtering method. Did you enable MIS in the Cycles render, at all? This paper makes a good argument on why sample sharing can actually be detrimental in combination with importance sampling, so you shouldn’t just assume that Cycles is using a “stupid” method.
I bet TS1234 not care about post pro noise filters in all PBRT rendrerers (luxrender and mitsuba) that turn on by default, as well as other similar biased anti-ferefly lux feature (postpone very low pdf samples to last second and maybe even drop them). Can be wrong ofc but…
Thanks for that link, Zalamander. It seems counterintuitive at first, but it does indeed look like it’s reducing monte carlo noise. I guessper-pixel stratification is preserved better? I’ll have to implement that in my own renderer when I find the time.
You can thank Matt for posting that paper on the previous page. I previously thought that the reason for Cycles sampling was mere simplicity, as well.
The key insight is that a sample with very high importance gets messed up by being weighted differently across pixel borders, during reconstruction.
(And yes, it also happens to be much easier on despeckle-like filters, to remove fireflies)
The link was already on the previous page? That answers storm_st’s question then - “Are you all blind?” - in my case, yes. 
Zalamander,
i do not read this paper before.
But i readed cycles and other source codes…
I wrote long time ago how it works in cycles.
It work same way how it is described in paper (and how i understand/described it)
This guy call it “filter importance sampling” (FIS) -
this have nothing to do with “importance sampling” (IS)
even if the name is nearly same.
As i wrote above (and the same i found in paper),
this FIS can not work good/correct with negative filter curve (mitchell, cat-rom…).
again: mixing sample to many pixels make smooth noise
imagine, you shoot a sample exactly between 4 pixels.
with mixing, all 4 pixels are affected, and you get “unsharp” noise,
because it is divided to 4 pixels at same time
(in reallity many more pixels can be affected: 5x5 = 25)
changing pixels is not so expensive than shooting samples.
it should be faster, because noise go faster away.
a sample is faster in FIS, but you need much more samples
to reach same noise level
it is possible to half the render time using other filtering with mixing.
because you can half the number of samples.
and plus: you can use other filters like mitchell
This guy call it “filter importance sampling” (FIS) -
this have nothing to do with “importance sampling” (IS)
even if the name is nearly same.
Lier. Go and learn about importance sampling and other methods calculating integrals http://en.wikipedia.org/wiki/Integral. It actually use importance sampling to solve integral of filter fiunction. It can be perfect exact function as Cycles use for filter, or close enouugh as in Glossy BSDF case, not matter because you continue absurd fantasy claim that uniform weighted sampling is better. I beginning to think you do not understand what is intergal at all, why it must be solved and 200+ history of all mathematic scientists fighting to make it more efficient . It seems you just love PBRT post pro median noise filter, so that is fine for me, but do not say it is related to main Cycles task.
This guy call it “filter importance sampling” (FIS) -
this have nothing to do with “importance sampling” (IS)
even if the name is nearly same.
Did you even read the paper? If so, you do not understand it. This has everything to do with importance sampling. You also didn’t answer my question whether you used MIS for your Cycles render. If you don’t use MIS, variance will be much higher.
you do not understand what i write.
this are 2 different things.
FIS and IS is not the same
FIS and IS are absilutely same. You definitely do not understand what is Importance sampling method.
i give up…
for me FIS look differnt than IS
FIS
http://lgdv.cs.fau.de/get/785
IS
http://igorsklyar.com/system/documents/papers/2/Mark.Presentation.pdf?1338790902
for me FIS look differnt than IS
Let’s ignore for a second the fact that you don’t understand what importance sampling is and answer me the following question:
Did you enable the MIS setting in the test renders you did? In Cycles, you must manually enable MIS for lights, environment, etc, in Mitsuba it is just on by default. There has been another flawed comparison of Cycles vs. Mitsuba where this was exactly the problem.
i have MIS enabled for lights
i have no time…
but it should really easy to “hack” cycles code for testing another filter method (with mixing pixels)
https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/cycles/kernel/kernel_passes.h
kernel_write_pass_float4() should not called from any path-tracer-functions
instead a new function is needed that write value to many pixels based on simple gauss filter
it need x, y, filter_x, filter_y (subpixel offsets) values and buffer start-pointer
https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/cycles/kernel/kernel_camera.h
camera_sample() should not “transform” filter coord - this disable FIS
thats it…
it will work only with one big tile…
we do not need a optimized version - only to compare images.
It wouldn’t be so easy to add to Cycles. A method of padding around tiles would have to be added at the kernel level, and a whole mess of code relating to the filer lookup tables would have to be taken out and replaced with traditional filtering methods. If you want to have a go, be my guest, but it’s such a small thing to get worked up over that I can’t see the point. You should be rendering to a clean image anyway, and no one will be able to tell how you filtered at that point.
A method of padding around tiles would have to be added at the kernel level,
this is not needed for testing if you use only 1 big tile
but a bounding check is needed, otherwise it will crash
and a whole mess of code relating to the filer lookup tables would have to be taken out and replaced with traditional filtering methods.
you can also ignore lookup tables and do not optimize code for speed
look up tables are used in camera_sample - replace only 2 lines and you have no more lookup tables
EDIT
i like to see 2 final images with 128 samples…
and noise in traditional filtering should look different (less noise)
but it is more complex to get it working with tiles…
you need extra border and overlapping tiles…
it is a big task… and at moment we do not need this.
Not on the filtering / sampling opic but still cycles related
Dingto has just comitted the Cycles - Non progressive integrator for the GPU… he has split the two kernels so that there is no speed penelty
http://lists.blender.org/pipermail/bf-blender-cvs/2013-August/058181.html
I was expecting to have non-progressive mode in GPU, works great. So good to have this feature. I just wish to have deformation motion blur with GPU in cycles to be completely happy
Dingto is bombing lately the SVN with really useful stuff…
I ask my self, when will Dingto will be under contract?!
He already is. He’s paid by Google to work on Cycles during this summer.