Here’s a simple, computationally easy, and always-working way to measure noise in renders with Cycles. I’m hoping it will get adapted into the Cycles main code.
This will DRAMATICALLY decrease rendering time because it finds areas that need to be sampled more and also for animations because you continue rendering until you hit your sampling threshold, instead of based on a constant number of render passes.
The computation takes less than 1 second of analysis for any image, and as I’ve shown it only needs to be computed for waaaaay less than 1% of the time during a render. I guess what I’m saying is NOT “noise” per se. Rather, the rate of change of pixel RGB values over time. Whether the renderer or compositor is making a “noisy” image on purpose due to complex textures, the fundamental measurement, since we have an iterative function, is the rate of change of the pixel value.
Here are the files:
http://dl.dropbox.com/u/10295145/jmil_MeasuringNoiseInCycles.zip
For example, one needs only to do a boolean subtract of one render from a previous render, convert to B&W, then analyze the histogram. As you can see from the attached files (.blend and analysis), this will ALWAYS follow a very predictable pattern.
Note also that these “booleaned” pixels actually can tell you where you should be sampling more, as these areas are going to be changing the fastest.
Hope that makes sense…
Anyway, you can see where the “noise” or the “undersampled” areas are very very easily. Look at the attached file “MeasuringNoise_008pass-004pass.png” to see what I mean. This has the 4 sample pass image boolean subtracted from the 8 sample pass image then converted to B&W.
shouldn’t this be VERY easy to make a part of the render? Maybe as an “Advanced option”?
Something like “Continue rendering until fewer than 10 pixels have a noise value under 64” as a default advanced setting.