POV-Ray : Newsgroups : povray.documentation.inbuilt : Anti-aliasing mode 3 Server Time
19 Mar 2024 01:09:43 EDT (-0400)
  Anti-aliasing mode 3 (Message 1 to 10 of 14)  
Goto Latest 10 Messages Next 4 Messages >>>
From: clipka
Subject: Anti-aliasing mode 3
Date: 16 Sep 2018 20:15:15
Message: <5b9ef213$1@news.povray.org>
As I'm writing this post, I'm about to finalize the integration of
UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.


This change affects the following command-line and INI file options:

Anti-aliasing options:

    Sampling_Method=n / +AMn             (now allows value 3)
    Antialias_Confidence=n.n / +ACn.n    (new)

General tracing options:

    Stochastic_Seed=n / +SSn             (new)


Description of Anti-aliasing mode 3:


This third, adaptive, non-recursive stochastic oversampling mode
repeatedly iterates over the pixels to be rendered, jittering each ray
randomly within the pixel on each pass, while keeping track of
statistical parameters such as average colour and mean deviation. On
subsequent passes, the algorithm ceases to oversample pixels where the
statistical parameters for the pixel itself and its immediate four
neighbors indicate that the result is "probably good enough".

What constitutes "probably good enough" is determined by a /confidence/
parameter specified by the `Antialias_Confidence=n.n` or `+ACn.n`
option, as well as a /threshold/ parameter specified by the
`Antialias_Threshold=n.n` or `+An.n` option.

The /threshold/ determines what absolute sampling error (i.e. difference
between the computed pixel colour and the theoretically correct one) you
consider acceptable, while the /confidence/ specifies how sure you want
to be that a pixel that /seems/ acceptable actually /is/ acceptable. In
effect, this determines how many pixels in the resulting image /will/
indeed be acceptable.

For example, if you specify a confidence of 0.95, then you can expect
approximately 95% of all pixels to be within the threshold (as compared
to a theoretically correct image). Of the remaining ones, many will be
off by slightly more than the threshold, while only few will be
significantly off, and extreme outlies are possible but extremely unlikely.

Recommended values are a threshold of 0.3 or lower, and a confidence of
0.9 or higher, which are the defults.

The total number of rays shot per pixel is limited by the
`Antialias_Depth=n` or `+Rn` parameter. As with the other modes the
parameter is limited to the range from 1 to 9, with the actual maximum
number of rays per pixel being 4^n.

By default, the sub-pixel jittering is different for each render, thus
giving slightly different results, with the intent that multiple renders
can be averaged to get a higher-quality image. To produce exactly the
same output each time, use the `Stochastic_Seed=n` or `+SSn` option.
(Note however that the jitter sequence is also affected by the actual
image content, and will thus always differ between the frames of an
animation.)

As oversampling mode 3 is a very generic adaptive oversampling
algorithm, its performance in pure edge anti-aliasing is generally
inferior to the other modes; however, it is ideally suited to suppress
random image noise created by other stochastic mechanisms, such as
jittered area lights, subsurface light transport, or micronormals-based
blurred reflections. It has also proven well-suited to eliminating moire
patterns.


Description of Stochastic_Seed / +SS:


By default, some stochastic mechanisms in POV-Ray intentionally give
different results for each render, with the intent that multiple renders
can be averaged to get a higher-quality image. To this end, the
corresponding pseudo-random number generators are seeded with a value
derived from the current date and time.

If the `Stochastic_Seed=n` or `+SSn` option is specified, the seed will
instead be derived from the specified value, allowing to produce exactly
the same output each time by specifying the same value.

Alternatively, the mechanism may be co-opted to prevent separate renders
started at the same time from producing identical results, by explicitly
specifying different values.

Note that even if the seed is set identical, other factors may cause
differences in the result, for example the render block size (+BSn) or
the render pattern (+RPn). Results may also differ between versions of
POV-Ray.

At present, the following features are sensitive to the stochastic seed
setting:

  - Anti-aliasing mode 3


----------------------------------------------------------------------


Differences to UberPOV (not intended for the docs):


* Threshold parameter:

UberPOV's anti-aliasing mode 3 required a threshold setting of 0.1 or
lower for good results, far lower than the default of 0.3 the other
modes are perfectly happy with. This is because UberPOV's mode 3
compared the differences of each colour channel to the threshold
individually, whereas the other modes compare the sum of all channels'
differences to the threshold instrad.

I have changed this in POV-Ray, so that mode 3 will also compare the sum
rather than the per-channel differences.


* Stochastic Seed:

UberPOV used a different seed for each thread (differing by 1), and did
not re-seed the random number generator between render blocks; as a
result, multi-threaded renders couldn't be reliably reproduced even when
explicitly setting the seed.

POV-Ray is re-seeding the random number generator for each render block,
using the specified seed + the running ID of the render block as the
actual seed. This allows to reproduce renders, provided that the same
render block size and render pattern are used.


----------------------------------------------------------------------


Additional related side notes (not intended for the docs):

The observant reader will note that the anti-aliasing mode 3's maximum
number of samples per pixel is close, but not identical, to the value
for mode 2 as specified in the docs in the table of `Antialias_Depth=n`
/ `+Rn` values.

It may be worth mentioning that the table for mode 2 is inaccurate in
that it doesn't take into account that samples at a pixel's corner or
edge are re-used for adjacent pixels where applicable. Only at the
render block border are edge or corner samples really used for one pixel
only.

So even the worst-case maximum per pixel in mode 2 is actually far
closer to 4^n than the (2^n+1)^2 given in the table.


Post a reply to this message

From: Jim Holsenback
Subject: Re: Anti-aliasing mode 3
Date: 19 Sep 2018 06:53:01
Message: <5ba22a8d$1@news.povray.org>
On 9/16/18 8:15 PM, clipka wrote:
> As I'm writing this post, I'm about to finalize the integration of
> UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.

ok... i've read and don't have any questions about what you've written. 
looks like a quick and easy add... only challenge will be finding time. 
should i bother generating distribution packages?


Post a reply to this message

From: clipka
Subject: Re: Anti-aliasing mode 3
Date: 19 Sep 2018 07:30:34
Message: <5ba2335a$1@news.povray.org>
Am 19.09.2018 um 12:53 schrieb Jim Holsenback:
> On 9/16/18 8:15 PM, clipka wrote:
>> As I'm writing this post, I'm about to finalize the integration of
>> UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.
> 
> ok... i've read and don't have any questions about what you've written.
> looks like a quick and easy add... only challenge will be finding time.
> should i bother generating distribution packages?

Yes, please. This time around I'm sure I'll find the time to actually
process them and include them in the repository.


Post a reply to this message

From: Jim Holsenback
Subject: Re: Anti-aliasing mode 3
Date: 22 Sep 2018 18:26:59
Message: <5ba6c1b3$1@news.povray.org>
On 9/19/18 7:30 AM, clipka wrote:
> Am 19.09.2018 um 12:53 schrieb Jim Holsenback:
>> On 9/16/18 8:15 PM, clipka wrote:
>>> As I'm writing this post, I'm about to finalize the integration of
>>> UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.
>>
>> ok... i've read and don't have any questions about what you've written.
>> looks like a quick and easy add... only challenge will be finding time.
>> should i bother generating distribution packages?
> 
> Yes, please. This time around I'm sure I'll find the time to actually
> process them and include them in the repository.

please review:

http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
http://wiki.povray.org/content/Reference:Tracing_Options#Stochastic_Seed

besides the am3 additions i also did some general cleanup and added a 
few visual cues to help better separate the method detail descriptions


Post a reply to this message

From: clipka
Subject: Re: Anti-aliasing mode 3
Date: 22 Sep 2018 19:39:36
Message: <5ba6d2b8$1@news.povray.org>
Am 23.09.2018 um 00:26 schrieb Jim Holsenback:

> please review:
> 
> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options

My thoughts on it:


Stochastic Seed:

- Typo: "Set's a value" should read "Sets a value".

Sampling Methods Synopsis:

- Excellent! Love this mini section!

Details, Type 1:

- The section states that "the adaptive non-recursive method is the
default". I would suggest adding "if anti-aliasing is enabled" or
something along those lines, because the "out of the box" default is no
anti-aliasing at all.

- It may or may not be worth also considering an optional alpha channel
in the formula given (but see further below).

Details, Type 3:

- The formula for the actual maximum number of rays per pixel is
literally written as "4^n" (four-caret-n), rather than using proper
superscript notation. Not sure if this is an oversight or technical
necessity. In the latter case, maybe Unicode character U+207F would be
an alternative to genuine superscript.

- The word "moire" in "moire pattern" lacks an accent.

Common section:

- The common section ("With all methods..."), as currently written,
implies that the `Jitter` setting affects all anti-aliasing modes; that
is incorrect: Anti-aliasing mode 3 always uses a constant amount of
jitter. I would suggest to use something like the following wording instead:

----------------------------------------------------------
Another way to reduce anti-aliasing artifacts is to introduce noise into
the sampling process. This is called jittering and works because the
human visual system is much more forgiving to noise than it is to
regular patterns, and is inherent in anti-aliasing mode 3. When using
one of the other methods, the location of the super-samples is also
jittered or wiggled a tiny amount jittering by default, but may be
turned off with the Jitter=off option or -J option, or the amount of
jittering can be set with the Jitter_Amount=n.n option. When using
switches the jitter scale may be specified after the +Jn.n option. For
example +J0.5 uses half the normal jitter. The default amount of 1.0 is
the maximum jitter which will insure that all super-samples remain
inside the original pixel.
-----------------------------------------------------------

Additional noteworthy information:

- It may be worth noting that if the image contains an alpha channel,
that channel will also be considered in the comparisons, pretty much
like the colour channels, except that unlike the other channels it is
not subject to `Antialias_Gamma`.


> besides the am3 additions i also did some general cleanup and added a
> few visual cues to help better separate the method detail descriptions

Would it make sense to use sub-headings instead of just bold text?

Also, I guess it might be useful to add another visual cue between the
type 3 description and the subsequent description of common features.


Post a reply to this message

From: Jim Holsenback
Subject: Re: Anti-aliasing mode 3
Date: 23 Sep 2018 07:36:12
Message: <5ba77aac@news.povray.org>
On 9/22/18 7:39 PM, clipka wrote:
> Am 23.09.2018 um 00:26 schrieb Jim Holsenback:
> 
>> please review:
>>
>> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
> 
> My thoughts on it:
> 
> 
> Stochastic Seed:
> 
> - Typo: "Set's a value" should read "Sets a value".

oops

> 
> Sampling Methods Synopsis:
> 
> - Excellent! Love this mini section!

at least it's better than the run-on sentence that used to be there

> 
> Details, Type 1:
> 
> - The section states that "the adaptive non-recursive method is the
> default". I would suggest adding "if anti-aliasing is enabled" or
> something along those lines, because the "out of the box" default is no
> anti-aliasing at all.

yep

> 
> - It may or may not be worth also considering an optional alpha channel
> in the formula given (but see further below).

if you /really/ think it's worth it help me out a bit...i /did/ do 
something near the end of common as there was already a +ag discussion 
going on... it seemed to fit.

> 
> Details, Type 3:
> 
> - The formula for the actual maximum number of rays per pixel is
> literally written as "4^n" (four-caret-n), rather than using proper
> superscript notation. Not sure if this is an oversight or technical
> necessity. In the latter case, maybe Unicode character U+207F would be
> an alternative to genuine superscript.

the hex equivalent was too small... 4<sup>n</sup> looked slightly better.

> 
> - The word "moire" in "moire pattern" lacks an accent.

found the hex version used elsewhere on the page

> 
> Common section:
> 
> - The common section ("With all methods..."), as currently written,
> implies that the `Jitter` setting affects all anti-aliasing modes; that
> is incorrect: Anti-aliasing mode 3 always uses a constant amount of
> jitter. I would suggest to use something like the following wording instead:
> 
> ----------------------------------------------------------
> Another way to reduce anti-aliasing artifacts is to introduce noise into
> the sampling process. This is called jittering and works because the
> human visual system is much more forgiving to noise than it is to
> regular patterns, and is inherent in anti-aliasing mode 3. When using
> one of the other methods, the location of the super-samples is also
> jittered or wiggled a tiny amount jittering by default, but may be
> turned off with the Jitter=off option or -J option, or the amount of
> jittering can be set with the Jitter_Amount=n.n option. When using
> switches the jitter scale may be specified after the +Jn.n option. For
> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
> the maximum jitter which will insure that all super-samples remain
> inside the original pixel.
> -----------------------------------------------------------

i mangled this paragraph on purpose because i was fishing for 
clarification... lol and you bit!

> 
> Additional noteworthy information:
> 
> - It may be worth noting that if the image contains an alpha channel,
> that channel will also be considered in the comparisons, pretty much
> like the colour channels, except that unlike the other channels it is
> not subject to `Antialias_Gamma`.

almost verbatim near the end...

> 
> 
>> besides the am3 additions i also did some general cleanup and added a
>> few visual cues to help better separate the method detail descriptions
> 
> Would it make sense to use sub-headings instead of just bold text?

ugh...i'm being lazy

> 
> Also, I guess it might be useful to add another visual cue between the
> type 3 description and the subsequent description of common features.

wasn't /feeling/ any of the several things i tried so i left it as is


Post a reply to this message

From: Jim Holsenback
Subject: Re: Anti-aliasing mode 3
Date: 23 Sep 2018 07:49:09
Message: <5ba77db5$1@news.povray.org>
On 9/23/18 7:36 AM, Jim Holsenback wrote:
>> ----------------------------------------------------------
>> Another way to reduce anti-aliasing artifacts is to introduce noise into
>> the sampling process. This is called jittering and works because the
>> human visual system is much more forgiving to noise than it is to
>> regular patterns, and is inherent in anti-aliasing mode 3. When using
>> one of the other methods, the location of the super-samples is also
>> jittered or wiggled a tiny amount jittering by default, but may be
>> turned off with the Jitter=off option or -J option, or the amount of
>> jittering can be set with the Jitter_Amount=n.n option. When using
>> switches the jitter scale may be specified after the +Jn.n option. For
>> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
>> the maximum jitter which will insure that all super-samples remain
>> inside the original pixel.
>> -----------------------------------------------------------

one more thing i just thought of...so is -j is useless if using +am3. 
does it throw a warning if the user specifies? i couldn't check because 
i'm in the middle of my variation of RSOCP...GSOPP (glowing spheres on 
pavement plane) beauty run


Post a reply to this message

From: clipka
Subject: Re: Anti-aliasing mode 3
Date: 23 Sep 2018 08:00:54
Message: <5ba78076$1@news.povray.org>
Am 23.09.2018 um 13:36 schrieb Jim Holsenback:

>> Sampling Methods Synopsis:
>>
>> - Excellent! Love this mini section!
> 
> at least it's better than the run-on sentence that used to be there

I consider it genuinely brilliant.


>> Details, Type 1:
>>
>> - The section states that "the adaptive non-recursive method is the
>> default". I would suggest adding "if anti-aliasing is enabled" or
>> something along those lines, because the "out of the box" default is no
>> anti-aliasing at all.
> 
> yep

Hm... the new version of the sentence seems garbled.


>> - It may or may not be worth also considering an optional alpha channel
>> in the formula given (but see further below).
> 
> if you /really/ think it's worth it help me out a bit...i /did/ do
> something near the end of common as there was already a +ag discussion
> going on... it seemed to fit.

I think that's good enough.


>>> besides the am3 additions i also did some general cleanup and added a
>>> few visual cues to help better separate the method detail descriptions
>>
>> Would it make sense to use sub-headings instead of just bold text?
...
>> Also, I guess it might be useful to add another visual cue between the
>> type 3 description and the subsequent description of common features.
> 
> wasn't /feeling/ any of the several things i tried so i left it as is

Mind if I mess with it? Then you can blame it on me if you're still not
totally happy with it ;)


Post a reply to this message

From: Jim Holsenback
Subject: Re: Anti-aliasing mode 3
Date: 23 Sep 2018 08:18:57
Message: <5ba784b1$1@news.povray.org>
On 9/23/18 8:00 AM, clipka wrote:
>>> - The section states that "the adaptive non-recursive method is the
>>> default". I would suggest adding "if anti-aliasing is enabled" or
>>> something along those lines, because the "out of the box" default is no
>>> anti-aliasing at all.
>>
>> yep
> 
> Hm... the new version of the sentence seems garbled.

my bad...it's been cleaned up

>>> Also, I guess it might be useful to add another visual cue between the
>>> type 3 description and the subsequent description of common features.
>>
>> wasn't /feeling/ any of the several things i tried so i left it as is
> 
> Mind if I mess with it? Then you can blame it on me if you're still not
> totally happy with it ;)

go for it...i haven't given up either


Post a reply to this message

From: clipka
Subject: Re: Anti-aliasing mode 3
Date: 23 Sep 2018 08:25:15
Message: <5ba7862b$1@news.povray.org>
Am 23.09.2018 um 13:49 schrieb Jim Holsenback:
> On 9/23/18 7:36 AM, Jim Holsenback wrote:
>>> ----------------------------------------------------------
>>> Another way to reduce anti-aliasing artifacts is to introduce noise into
>>> the sampling process. This is called jittering and works because the
>>> human visual system is much more forgiving to noise than it is to
>>> regular patterns, and is inherent in anti-aliasing mode 3. When using
>>> one of the other methods, the location of the super-samples is also
>>> jittered or wiggled a tiny amount jittering by default, but may be
>>> turned off with the Jitter=off option or -J option, or the amount of
>>> jittering can be set with the Jitter_Amount=n.n option. When using
>>> switches the jitter scale may be specified after the +Jn.n option. For
>>> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
>>> the maximum jitter which will insure that all super-samples remain
>>> inside the original pixel.
>>> -----------------------------------------------------------
> 
> one more thing i just thought of...so is -j is useless if using +am3.
> does it throw a warning if the user specifies? i couldn't check because
> i'm in the middle of my variation of RSOCP...GSOPP (glowing spheres on
> pavement plane) beauty run

`+j/-j` has no effect whatsoever when using `+am3`.

I'm not sure whether throwing a warning would be the right thing to do;
it's not general policy to throw warnings for using INI file or
command-line settings that turn out to be without effect due to the
other settings. For example, `+am3` by itself (without `+a`) has no
effect either and also doesn't give you a warning.

This actually makes sense, if you consider that you can set up INI stuff
in the master povray.ini. For example, a user might deliberately specify

    Antialias=off
    Sampling_Method=3
    Antialias_Confidence=0.95
    Antialias_Threshold=0.02
    Jitter=off
    Jitter_Amount=0.2

in their povray.ini to tell POV-Ray that they normally want no
anti-aliasing, but if they do they prefer method 3 with a confidence of
95% and a threshold of 2%, and if they choose a different method they
want no jitter, and if they explicitly turn on jitter they want just a
little of it.

Such a user wouldn't want a warning every time they start a render.


The portions of POV-Ray concerned with the /semantics/ of the ini and
command-line settings cannot tell whether they came from a povray.ini, a
quickres.ini, a scene-specific ini or the command-line, whether they
were specified using ini file style or command-line style, nor even the
order in which they were issued, so they are unable to tell whether the
specific settings were intentional as in the above example, or by
mistake as might be presumed in a `+am3 -j` command-line.


Post a reply to this message

Goto Latest 10 Messages Next 4 Messages >>>

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