POV-Ray : Newsgroups : povray.general : Correcting comments on Anti-alias (AA) modes and jitter. Server Time: 28 Nov 2020 13:52:10 GMT
  Correcting comments on Anti-alias (AA) modes and jitter. (Message 1 to 1 of 1)  
From: William F Pokorny
Subject: Correcting comments on Anti-alias (AA) modes and jitter.
Date: 30 Oct 2020 17:15:27
Message: <5f9c4a2f$1@news.povray.org>
Recently, over in povray.beta-test-binaries, I made a comment with 
respect to the new method 3 AA mode (+am3) in v3.8 being better for 
render to render results due being able to seed the random number 
generator with that mode.

Kenneth asked for clarification and both of us tried multiple same scene 
renders looking for differences due AA jitter being on. We saw none. 
This led me to dig into the code earlier this week.

---
I long, and wrongly, thought AA methods 1 and 2 employed a random jitter 
render to render. There is documentation which - to me - reads in a way 
aligned with this belief:

http://wiki.povray.org/content/Reference:Tracing_Options#Common_Properties

has the following note:

"Note: The jittering noise is random and non-repeatable..."

For years I ran AA with -j to turn jitter off when I wanted 
repeatability. In fact, I often run without AA so it doesn't hide 
problems - and so AA jitter not in play.

Going back to at least v3.6 the jitter of AA modes 1 & 2 is exactly the 
same render to render. Today it is only the new AA mode 3 which is truly 
random render to render -unless the seed (+ss) is set by the user.

Prior to v3.7 and threading, there was a global variable continuously 
incremented and added to each x then y as every pixel was traced. These 
values were used as inputs to multiple hash indexing into a 256 entry 
table of single float offsets. This was a decent method to visit all two 
value pair possibilities in the table of 256 +-0.5 values.

With threading (v3.7+) there is no longer a global variable. Some change 
was made to vary x and y inputs to the hashing, but I think these help 
not all that much. I could ramble a while with details, but basically 
this method less good at generating all the pair combinations - 
especially when you look at small sub-windows of a larger render. In 
fact, in sub windows of 50x50 pixels no jitter was as good or better in 
AA at generating unique offsets.

I'll toss out too that at 300x300 windows, the jitter -- x,y 
pairs/offsets generated are already less than 8% unique at super 
sampling >4 / pixel.

I'd also long made a bad assumption that the jitter value was scaling 
down only as the sub-pixels scaled down in the recursive methods 1 & 2. 
What actually happens is the input jitter amount is scaled immediately 
depending on the recursion depth (R) specified. The internal jitter 
scaling values are the J columns below.

For example, when running +am2 +r3 +j1.0, the internal jitter scale is 
0.111 * what comes out of the 256 entry jitter value table with max 
values of +-0.5. So, we are getting a max jitter of only +-0.055 in that 
case and all inside the pixel boundary.

The internal jitter scale is set for the smallest possible sub-pixel 
(the largest recursion depth) whether or not that depth is necessary 
given the threshold.

R   am1 J   am1 Jc   am2      am2 Jc
---------------------------------------
1  1.00000  1.00000  0.33333    3.00000
2  0.50000  2.00000  0.20000    5.00000
3  0.33333  3.00000  0.11111    9.00000
4  0.25000  4.00000  0.05882   17.00000
5  0.20000  5.00000  0.03030   33.00000
6  0.16667  6.00000  0.01538   65.00000
7  0.14286  7.00000  0.00775  129.00000
8  0.12500  8.00000  0.00389  257.00000
9  0.11111  9.00000  0.00195  513.00000

The Jc column above is what the +j<value> would need to be to get a 
constant jitter with respect to the pixel size with each recursion 
depth. Today the jitter value is clamped to a 0.0 to 1.0 range, so 
knowing larger values might be of use - is of no use.

What I've coded up now in povr is AA jitter defaulted off. This saves a 
little time when using AA and in practice the jitter on in v3.7+ isn't 
better anywhere that I've tested. It's different, so sometimes, yeah, 
different will look better.

I've also removed the upper clamp on the jitter amount - it can now be 
huge. Renders for 500+ values give a noisy effect, but an image that's 
still pretty much what you'd expect due bouncing often outside each 
pixel's boundary.

Lastly, I've replaced the hash/jitter table with c++ random number 
generators. Now with +j, I get random jittering and the x,y offsets in 
that 300x300 test are 100% unique - but also now different render to 
render like method 3.

Aside 1: The same 2d jitter code was used in the focal code so I created 
a version just for focal blur leaving the behavior the same for now. 
Though +j (or some other method) turning on focal blur jitter which is 
more random probably worth doing.

Aside 2: In the focal blur code there are random number generators 
perturbing the x,y inputs. This means the jitter with it more like what 
the pre v3.7 AA jitter used to be - with respect to walking all the pair 
possibilities in a way less clustered.

These asides lead me to mentioning other jitter methods in POV-Ray. I'm 
only focused on the AA method 1 and 2 one herein.

Likely not 100% a complete list and perhaps my understanding of behavior 
sometimes wrong too, but for v3.8 (povr):

(With jitter value >0)
-----------------------
AA method 1&2 jitter not random at all render to render(r-r).
AA method 3 random jitter (r-r) unless seeded.
Media jitter random (r-r).
Area lights jitter random (r-r).
Photons jitter random (r-r).
Rainbow jitter random (r-r).

Isosurface jitter random (r-r) (povr only).

Focal blur, as previously mentioned, internally uses random (r-r) jitter 
into the 256 value jitter table which today is not user controllable, 
but (r-r) differences likely hard to detect. A jitter enhancement here 
allowing more user control might be useful, but it's not an option I use 
much.

Oh! I looked at one last thing - the +ag feature for AA. I have used it 
in an old image with strong, narrow highlights. Otherwise, it doesn't 
seem to do a lot - for my usually simple scenes in any case. In my tests 
with simple scenes and hacking controls to get near the same number of 
AA samples, I'd put the cost in the 4% range of the entire render cost. 
It's not all that cheap. I wonder if tweaking the threshold - which 
we've always been able to do - would not offer results as good at no 
additional expense. Anyone have more experience with +ag settings other 
than the default 2.5?

Bill P.


Post a reply to this message

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.