First rendering with NPR
LEFT: 129 passes (not samples per pixel) 24m:30s
up to 10 samples per pass and pixel
but most time 2 samples was rendered
RIGHT: Official Blender 261 (with border-bug)
~260 samples per pixel 24m:30s
i should rebuild official 261 on my machine - that eliminate speed differences
Before anyone starts wondering if there are actually any differences. You can actually notice a significantly lower amount of noise within the caustic regions near the bottom of the image rendered using the NPR functionality, this is despite the fact that the no. of passes for that image is significantly less than the image rendered with the official release.
So in light of that, I personally can’t wait to see the first builds containing this feature (don’t forget win32) 
This approach should give us also a nice option: final (visual) quality of the image. A parameter which can be used to trigger the termination of a render process. Can be useful for stills and probably for animation:
if quality=X then skip to next frame
As others, lookin’ forward to see tests…
Yet another thread of awesomeness.
very great developments! thank you for your work on this patch
Great progress. I’m very excited seeing this in interior scenes. 
Before anyone starts wondering if there are actually any differences. You can actually notice a significantly lower amount of noise within the caustic regions near the bottom of the image rendered using the NPR functionality, this is despite the fact that the no. of passes for that image is significantly less than the image rendered with the official release.
here are nearly the same number of samples - but they are differently placed
this was first image with pixel-based samples - and the result in good so far
This approach should give us also a nice option: final (visual) quality of the image. A parameter which can be used to trigger the termination of a render process.
i thought first this noise-termination is not possible, but i found now a nice idea
I know it’s likely that you would need more than a few days to get this feature ready for testing, but do you have any updates on progress? I ask because I personally see this as a potentially major optimization for the Cycles engine that will allow us to render out images a lot faster than before and I wouldn’t want to see this fall on the wayside.
i have 2 ideas for NPR - i dont know what is the best - I rewrite NPR now
First idea: micro-renderbuffer that hold only few samples (16) and compare this with final image - this was the first code. Here is a problem with shadows that create “flickerings” (sometimes are pixel full black 0,0,0) - i think i can solve this - i come back to it later.
New idea is to split samples into 2 buffer and compare this buffers
New noisemap looks very very good now - but the render result is not so good.
I need more tweaking (influence pixel neighbour) or more buffers for this…
Here are 2 images:
color image come from original blender 2.61
new image with NPR look a bit more noisy - so i do not post it here
Remember, Cycles use Quazi random sequence, not usual random ( congruential ) generator, it make very correlated samples sometimes. You can turn off that commenting out line in kernel_types.h with #define SOBOL . You cannot just compare current pass pixel color with rest, at least you need to accumulate more (20? 200? who know) passes before comparison. If it were that simple then every path tracer around would have that feature.
I see, what you’re getting into can be some pretty tricky stuff, it sounds like this could take a while to get right for every type of scene.
Have you tried using a method in which the noisemap would be divided into tiles, and thus the NPR will check all of the pixels within to determine if it should continue to be sampled? In theory, you could then avoid cases of pixels not being correct and thus retaining noise because you’re checking a an entire region of the image rather than just the pixel, so the rendering would continue for pixels being displayed as noise-free, because the tile itself contains other pixels that are grey or white.
In other words, you might be checking say, 8x8 pixel tiles repeating across the entire image, if the noisemap contains just a few pixels that are not considered noise-free, the sampling would continue. The sampling would only cease for the region if the entire area is considered noise-free or the highest value is below a certain allowance threshold.
Combine that with moving the noise-checks to once every N-passes and you could theoretically have a system that produces a noise-free result with virtually any scene type.
You cannot just compare current pass pixel color with rest, at least you need to accumulate more (20? 200? who know) passes before comparison.
this is what i do
If it were that simple then every path tracer around would have that feature
i belive that this is possible - i demonstrated that it is doable to detect noise
this idea was for LuxRender - but no developer was interested
i decided to modify cycles - since cycles is faster - and the render-engine not so complex
But cycles work different - you can see it here
both images with 2 samples per pass / pathtracer
left cycles (fast) - right lux (slow)
note that lux produce noise that is not so hard than that from cycles
i need 16 samples per pixel for results that looks like that from lux
i think also that NPR do not solve every problem (fireflies?)
Have you tried using a method in which the noisemap would be divided into tiles, and thus the NPR will check all of the pixels within to determine if it should continue to be sampled? In theory, you could then avoid cases of pixels not being correct and thus retaining noise because you’re checking a an entire region of the image rather than just the pixel, so the rendering would continue for pixels being displayed as noise-free, because the tile itself contains other pixels that are grey or white.
Cycles is already tile-based. NPR renders tiles - but not so you think
Is is possible that a tile render only 1x per pixel - but another tile render 5x per pixel.
but here is no threshold - because NPR can not detect “noise” - it detect only “non-stable pixels”. This is a difference! NPR renders without knowing how noisy a pixel is. NPR “think” that a non-stable pixel need more samples - it flood that pixel with more samples. it is also possible that NPR flood a pixel with too many samples - or not enought samples (but you should control this itself using “max-spp”)
My second NPR-idea with 2 buffers go to the direction of detecting noise - but the result is not so good - this is the issue with non real random numbers, i think
This is similar to what I mean, in that a certain region of the image would continue to be sampled because the noise-map would indicate that the tile would still contain a few non-stable pixels, that would depend on if the algorithm involves cross-checking with the noise-map that is generated. In other words if all the pixels in a region are not yet ‘stable’, then sampling continues.
I know you said there is no threshold, but wouldn’t you be able to see the maximum color values of the brightest remaining pixels in the noise-map as something similar to one?
I respect that you know a bit more about the subject than I do and you know what’s needed to be done yet, I am also aware that this can be tricky stuff and I respect your work in trying to resolve any issues that might come up, but I’m quite eager to see this functionality in Cycles sometime soon. 
some tests
1 Monkey 50 sampl (without NPR)
2 Monkey-Noisemap with 16 spp
3 Monkey-Noisemap with 32 spp
In these images, the last one of the car for example just above this post, white pixels means pixels that are not stable so they are being rendered with more samples?
Well, then I think you are forgotting the dark pixels between these non stable pixels. Obviously they are considered stable but being in a inestable zone I am sure they have a wrong calculated value on them so the noise will persist. The solution would be consider non stable too the eight pixels that surround one inestable pixel. If I am right the image would be better. Perhaps even would be better consider inestable the 24 pixels surrounding one inestable pixel. It would be valuable to test both cases and see what is better.
jep, i am adding “cleaning” and “smoothing” the map for that
with defined nr of iterations
“cleaning” check if here are pixels with higher intensity
“smoothing” copy 50% from neighbour pixels - so it look more unsharp
left without npr (15:11 - 120 passes or so) - right with npr (14:33 - 53 passes or so)
noisemap after 200 passes - with neighbour pixel smoothing
wow! 120 vs 53 passes and the look is so similar! these results are promising indeed! the question is, how to make each pass faster, because time-wise the difference is not that awesome
you should not compare passes
