[Bf-cycles] Base 'Render' samples (simple request)

[Jordan Miller]

It's not impossible at all and I've just done the analysis (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.

Again, this will DRAMATICALLY decrease rending time for animations because you continue rendering until you hit your sampling threshold, not based on a constant number of render passes.

thoughts?

jordan



On Nov 11, 2011, at 5:24 PM, storm wrote:

> В Пт., 11/11/2011 в 14:18 -0500, Jordan Miller пишет:
>> couldn't the compositer or the cycles engine measure the noise
>> reduction with each successive pass and thereby achieve a user defined
>> noise threshold? it would allow standardization of all renderings
>> (rendered to a noise level of ## dB across >90% of the image)...
> 
> Unfortunately it impossible. You only can guess variance decay using
> 1/(sqrt(N)) with N = number of passes. Any statistically based
> measurements far from what we see by eyes. Maybe complex psy-based
> algorithm exist, but i doubt it can utilise fact that only portion of
> moving picture take more attention then other. Random generators not
> perfect, there always be some parts of image that too noisy and stay
> noisy in next frame, so you get false positive.
> 
>> 
>> as people start to use cycles for animations choosing a pass value
>> high enough for complex frames may oversample simpler frames and
>> unnecessarily increase render time. having the end user figure out
>> which individual frame will have the most noise is also non-trivial.
>> 
>> being able to simply set a "noise level" IMHO would be cleaner
>> interface and technically more accurate for what the end user is
>> trying to achieve, while also being scalable to animations and any
>> desired rendering or compositing complexity.
>> 
>> thoughts?
>> 
>> jordan
>> 
>> 
>> 
>> On Nov 11, 2011, at 2:04 PM, Brecht Van Lommel
>> <brechtvanlommel at pandora.be> wrote:
>> 
>>> I don't think this is needed, there is no right value anyway, it
>>> depends on the scene. I'd rather have a low value that can be
>>> increased later. There's currently no way to render something without
>>> understanding that this value needs to be tweaked anyway.
>>> 
>>> Brecht.
>>> 
>>> On Thu, Nov 10, 2011 at 6:59 PM, David Black <db4tech at yahoo.co.uk> wrote:
>>>> Hi Brecht,
>>>> How do you feel about changing the base 'Render' samples from 10 to 1000 (or
>>>> 500 at the very least)?
>>>> Thought it might save complaints and help new users, who don't understand
>>>> why their new Cycles renders are noisy.
>>>> Thank you kindly for all your hard work, very much appreciated,
>>>> my degree work would not have been possible (using Blender) without it!
>>>> David
>>>> 
>>>> _______________________________________________
>>>> Bf-cycles mailing list
>>>> Bf-cycles at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>> 
>>>> 
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
> 
> 
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles