[Bf-committers] Does Cycles waste half it's possible performance or am i wrong?

[Brecht Van Lommel]

Hi,

I'm not going to spend more time on this discussion. The paper I
linked to shows that the situation can be reversed even in some
scenes, and I don't think your reasoning is correct. I understand that
it would lead to less noise in other cases to implement the filter
differently, and I agree it would be useful to do this once, but I
don't think it's anywhere near the noise reduction you are suggesting
in common cases. If you want to convince me of that I'd need to see
some actual render results to demonstrate this.

Brecht.

On Sun, Oct 28, 2012 at 5:42 PM, Tobias Oelgarte
<tobias.oelgarte at googlemail.com> wrote:
> Am 28.10.2012 13:45, schrieb Brecht Van Lommel:
>>
>> It will waste samples, but how many does it really waste for a filter
>> of size 1.5-2.0? If you use larger filter widths it wastes more, but a
>> gaussian filter of 3.0-4.0 will already blur out all your edges.
>>
>> My point was not that the gaussian filter reduces noise, but that it
>> further reduces that 2x less noise number you gave. If a sample
>> contributes 0.05 to one pixel and 0.95 to another, it doesn't affect
>> noise by the same amount.
>>
>> Brecht.
>>
>
> At the moment i will limit my answer to only this topic, because it is
> the important one. To help understanding i will use an strongly
> simplified example, but which can be expanded to the general case.
>
> Lets assume we have only two pixels and ignore the y-Axis entirely,
> using only a line in-between both pixels center points (reducing the
> problem to 1D). The first center is to the left (at x=0) and and other
> one is to the right (at x=1). That means that all samples are on this
> line, ignoring the left half of the left pixel and the right half of the
> right pixel entirely. Now i define that the ideal values (that infinite
> rays would find at this location) would be a ramp. That means the ideal
> value for x=0 would be 2 and the ideal value found for x=1 would be 4
> and for x=0.5 it would be 3. Since we use pathtracing we don't get this
> results right away. We get the ideal result (r) + an error (e) for a
> sample (s).
>
> s = r + e
>
> For "e" i assume it to be the same as r, which resembles the situation
> that half of the rays don't give a result and the other half produces
> the double result, so that the average is r and the average of e is zero
> for infinite samples.
>
> If i now assume that we would use the current algorithm and the 1d-box
> filter (box distribution) instead of gauss to keep things very simple.
> If would now start to sample i would need to decide which pixel (center)
> i want to use. I randomly pick one of them (0.5 probability for each),
> but let us stay at the first (left) pixel. The box filter produces a
> random value between 0 and 0.5 (we ignore the left side) and he will get
> s_n = r_n + e_n for this pixel.
>
> It is easily to see that ideal value for this pixel would be 2.5:
>    0.0:  s_0 = r_0 + e_0 = 2 +- 2
>    ...
>    0.5:  s_h = r_h + e_h = 3 +- 3
>
> For many samples the average of r_n is 2.5 and e_n will be 0, giving
> 2.5. Now we can look at the error and how strongly it decreases per
> sample in average. It should be clear that the average error is halfs
> for every double amount of samples. Nothing unusual so far. But we have
> to remember that we have two pixels (two halfs). To get the same
> relative error reduction for both of them we need to send four times the
> amount of samples inside the scene to half the error.
>
> Now we do the same with an algorithm that only chooses an random x
> (0<=x<=1) and contributes it to both pixels. Of course a sample with x=0
> will only contribute to the left pixel, while a sample at x=0.5
> contributes to both of them with weight 0.5. At first sight it means
> that every ray would only contribute the half amount in average to a
> pixel and that there should be no difference. But this isn't true. There
> is the other half that now contributes with an average weight of 0.25 to
> the pixel and helps to reduce the noise, which was not present in the
> first case. If we now count in the other halfs of the two pixels
> (assuming they are part of a continuous row)  then this percentage will
> not change, because it is the other half. But we are still in 1D. If we
> also use the y-axis then this increases to 0.5. This means that we get
> the double amount of samples contributing to a pixel in comparison to
> the current box filter. The size of the filter does not matter all since
> the error and the result is not spread around multiple pixels. It only
> affects the sharpness of the pixel (his frustum) himself.
>
> Thats why i said that we have to expect a factor of two in noise
> reduction without loosing sharpness at all. The same is also true in
> comparison to the gauss filter, which does not help in noise reduction.
> It actually creates noise depending on the situation.
>
> Tobias
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers