Better understanding of GitHub issue 377 regarding partial render 
differences as compared to full renders.

https://github.com/POV-Ray/povray/issues/377

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d07acb1d24138982bedecc40%40news.povray.org%3E/

(Unable to update the thread above due corruption from server crash some 
ago)

The differences highlighted in the forum post and issue above come down 
to jitter values both as external settings to antialiasing(AA) and 
internal random sampling (a kind of jitter too) part of method 3's AA 
algorithm.

All three methods are exposed to differences on partial renders when AA 
jitter is on. Method three is always exposed because internally it uses 
a random number stream to generate the samples even when the 
Stochastic_Seed=n / +SSn is used.

Excepting AA method 3, turning off jitter solves the full to partial 
render difference issues.

---
With jitter on and always with method three the following helps reduce 
the full render pixel to partial render pixel differences:

a) A smaller threshold value (and method 3 also confidence value).

b) Colors matter because the threshold difference is based on a 
calculated grey equivalent.

c) The new to yuqk minimum sample depth via Antialias_Min_Depth=n ini / 
+RMn settings help when >0.

d) The yuqk fork no longer use a fixed table in methods 1 and 2 when 
jitter is on. This method tends to be less sensitive to partial vs full 
renders, but this statement depends quite a lot on the block sizes and 
ordering used on the partial rendering versus the full rendering.

e) Method 3 will always be exposed to differences on partial renders 
versus full renders.

f) Method 2 (with jitter) the least exposed because of how is so 
drastically shrinks the non zero jitter value on depth/+r. Yes, it's 
also true the deeper the depth/+r settings with both methods 1 & 2 the 
less likely partial render to full render differences will show up.

g) Related to (f) the partial to full render differences are more likely 
to show up where yuqk's big jitter value is larger than 1.0.


Aside: As of writing this I'm unsure what happens with render 
continuations.  If the position in the random number streams are 
maintained in the state file, continuations should work without issue. 
Otherwise continued renders may well show differences when compared to 
renders not stopped and re-started.

Bill P.

Post a reply to this message

On 25.01.2024 16:49, William F Pokorny wrote:
> Aside: As of writing this I'm unsure what happens with render 
> continuations.  If the position in the random number streams are 
> maintained in the state file, continuations should work without issue. 
> Otherwise continued renders may well show differences when compared to 
> renders not stopped and re-started.

Using a random sampling and then always expecting the same result is a 
user error, not a bug. The random effects may also depend on the thread 
settings, block size settings, hardware used, etc. because they are 
random. As such, clearly not a bug.

Thorsten

Post a reply to this message

On 1/26/24 07:20, Thorsten wrote:
> On 25.01.2024 16:49, William F Pokorny wrote:
>> Aside: As of writing this I'm unsure what happens with render 
>> continuations.  If the position in the random number streams are 
>> maintained in the state file, continuations should work without issue. 
>> Otherwise continued renders may well show differences when compared to 
>> renders not stopped and re-started.
> 
> Using a random sampling and then always expecting the same result is a 
> user error, not a bug. The random effects may also depend on the thread 
> settings, block size settings, hardware used, etc. because they are 
> random. As such, clearly not a bug.
> 
> Thorsten
> 
> 

:-) True as written. I agree well enough that I closed the github issue 
once I understood why the partially rendered regions where sometimes 
showing differences.

We should though, avoid setting a universal impression AA jitter should 
be avoided where users want repeatable render to render results. This 
especially true in the very latest yuqk release where the v3.8 method 3 
+ss mechanism has been extended to all three AA methods. Being able to 
use a good jitter and get repeatable results is effectively a new, 
desirable feature.


---
The AA / jitter reality across v3.6 -> v4.0 & my yuqk fork is 
complicated over time - as I think might reasonably be user expectations.

Speaking only of anti-aliasing / jitter affected results...

With the latest yuqk release - so long as +ss is set, the render 
pattern, step size and block size is held constant and we are doing full 
frame renders - results are repeatable no matter the number of threads 
used and no matter whether jitter is used or not (jitter of course 
always on or off).

A similar statement can be made for official releases and (non-buggy) 
method 3 (v3.8+) results using jitter or not. Methods 1 & 2 jitter 
onward in official v3.7 onward are mostly repeatable too (jitter is 
using a static table and jitter defaults on), but here the statement is 
weaker as is the quality of the AA when jitter is on.

Users expecting that a partially rendered region of a frame should match 
the same region when the frame is fully render isn't that much of a 
stretch, if they are seeing frame to frame repeatability. The same true 
for renders stopped and restarted via state files - though again, I 
don't myself know what is or is not happening with continued renders 
with respect to jitter / method 3(a).

Bill P.

(a) - If the continuations start after the last full block rendered in 
the context of the an identically ordered (and block numbered) render 
pattern, probably things work fine.

Post a reply to this message