> It is a clear correction to previously incorrect behavior.  Previously
> POV-Ray was broken, it no longer is.

The previous behavior was correct; the current behavior is broken.

There was one single reason that people complained about the 3.5
antialiasing: the fact that it made objects which were smaller than one
pixel (stars) disappear.

Well, duh. If an object is 1/10000 of the image's width, then of course it
should be nearly invisible! The solution to the problems that these people
were having was to make their stars larger.

The reason people use antialiasing is to remove the jagged edges that are a
result of a finite resolution. The point of antialiasing is to simulate an
image of infinite resolution.

Now, let's say that my monitor had an infinite resolution. If I rendered an
infinite resolution image without antialiasing ('cause it wouldn't be
necessary), and displayed it on my monitor, what would my eyes see? They
would see what looks like the output of a POV-Ray 3.5 image, and not the
output of a POV-Ray 3.6 image.

I recognize that the 3.6 behavior is useful, but that usefulness is limited
to occasional situations, including the creation of stars with very tiny
very bright objects. But that is a misuse of the antialiasing feature. If I
make a little star shaped object (an actual star shape with 5 points), scale
it real tiny, make it bright and put it far away, and the renderer
interprets that as a square of light (a white pixel) on my screen, how is
that correct? Now, a grey pixel caused by the averaging of white samples and
black samples is not a star shape either, but it more accurately reflects
the area that my star shape covers out of the square pixel.

The oversaturation of an entire pixel from a single very bright sample can
be useful in this situation if that's the effect the user wants. However, if
it's usefulness that we're going for, then consider the recent images in
p.b.i.

At least twice now, users have posted images that suffer from bad
antialiasing, one of them even asking what was going wrong. Our answer was,
"you're making things too bright." So now, it seems, the user is required to
make scenes without bright objects if they want them to look good. That
doesn't sound very useful to me at all.

This isn't even restricted to colors like rgb 1000. If I made a sphere with
color rgb 2, the artifacts would show up along the more brightly lit parts
of the sphere. Setting the sphere's color to rgb1 would fix the problem, but
*change the appearance of the sphere* even where the antialiasing was *not*
a problem. The 3.6 antialiasing restricts my artistic freedom in a way I
can't even work around.

The solution to the "antialiasing ruins my stars" problem was always "use
bigger stars." The solution to the new "antialiasing ruins my bright
objects" problem is "POV-Ray 3.6 doesn't allow you to use bright objects."
This is a severe limitation. So if usefulness is the primary concern, then
the 3.5 antialiasing was a much better choice. It can also be pointed out
that the star problem was something that new users tended to be troubled
with, while the bright objects problem is something more likely to affect
experienced users, and therefore it has a much higher chance of ruining
*good* images.

But let's say that correctness is the primary concern. Well, it is difficult
to say what is "correct" in this case. The reason being that antialiasing
has always been a bit of a hack feature (not just in POV-Ray but in
everything); it tries to simulate high resolution where only low resolution
is available, and it does this by altering pixel colors.

I think, however, that there is one thing everyone can agree on: the primary
purpose of antialiasing has always been to remove jagged edges. POV-Ray
3.6's antialiasing does not always do that anymore.

I still argue that the output of an antialiased image should be the same as
if the image was rendered at infinite resolution and then sized down. That
is no longer the case in POV-Ray.

I admit that the new functionality is occasionally useful, which is why I'm
OK with Rune's suggestion to make it optional. But it should not be the
default.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

> Because this 'solution' causes a lot of trouble (among others making HDR
> image output impossible without larger hacks).  And it does not solve
> the problem of non-linear tone mapping applied after the antialiasing
> step limiting the quality of the antialiasing results.

How does gamma correction after antialiasing limit the quality of the
antialiasing results?

If viewed on a monitor for which the gamma correction was correctly
performed, the gamma correction should exactly cancel out the monitor's
gamma effects, producing the original image as though non-linear tone
mapping never happened in the first place.

Gamma correction should always be done as the last thing in a renderer's
output. In fact, if the user plans to do anything more with the output
image, then they should turn off gamma correction, do whatever
postprocessing they want, and *then* apply gamma correction. Then, when the
image is displayed on a monitor, the gamma effects will cancel out the gamma
correction and present the viewer with the correct image.

> > So clip it at the maximum value that the output format supports? Which
> > happens still to be 1.0 at the vast majority of supported formats.
> >
>
> Could it be that you did not understand the fundamental difference
> between a HDR and a conventional image file format?  It does not make
> sense to speak of a maximum value in a HDR image file format, even if it
> has a theoretical maximum value.

HDR image output samples should be clipped, as Rune said, to the range which
the format supports. If HDR supports negative values, then the output should
be clipped to the range (-infinity, infinity) or in other words not clipped.
If it doesn't, then the output should be clipped to the range [0, infinity).

After this clipping, samples should be averaged together.

Finally, gamma correction should be applied as the last step as I mentioned
earlier.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Rune wrote:
> 
> Could you refresh my memory in what exact order things are handled now?
> First antialiasing, then gamma-correction, then color clipping? Where does
> the non-linear tone mapping fit in? Is it the same as gamma correction?

The term 'tone mapping' is used for the combination of all operations 
used to map the light intensities returned by the raytracer to the color 
values of the images.  In the simplest case this is no operation at all 
but in most cases you will use at least clipping and gamma correction. 
More sophisticated techniques exist which usually make the clipping 
completely unnecessary because the mapping function maps the infinite 
range of possible intensities to a finite interval.

POV-Ray 3.6.1 does antialiasing with the unmodified intensity values, 
clips them, gamma corrects them and then writes them to the file.  In 
MegaPOV (1.0 and later) the film exposure is (when enabled) applied 
before the clipping and in fact makes it unnecessary (it is still there 
but has no effect).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Slime wrote:
>[...]
> 
> I think, however, that there is one thing everyone can agree on: the primary
> purpose of antialiasing has always been to remove jagged edges. POV-Ray
> 3.6's antialiasing does not always do that anymore.

The effect you get with antialiasing in POV-Ray 3.6.1 is like rendering 
in high resolution to a HDR image and scaling it down.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> POV-Ray 3.6.1 does antialiasing with the unmodified intensity values,
> clips them, gamma corrects them and then writes them to the file.

And what exactly was wrong about clipping before antialiasing, as long as
gamma correction is applied after antialiasing?

Better yet, reply to Slime's post, since it deals with details I haven't
written down here.

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

I think I agree with Thorsten and Christoph that 3.6 behaviour is
mathematically correct and that 3.5 had a bug/feature.
I think I was a feature as it allowed us to create scenes that
looked like we wanted, eventhough it was based on faulty code.

I don't agree with Thorsten that everbody now has to change
their scenes and that from now on it is de facto forbidden to
use bright objects. Or that at least we are not allowed to
complain if that results in jagged edges.

I do agree with Christoph that some solution has to be found to
counter this unwanted phenomenon. I find his response more
constructive than Thorston's.

Post a reply to this message

Christoph Hormann wrote:
> The effect you get with antialiasing in POV-Ray 3.6.1 is like
> rendering in high resolution to a HDR image and scaling it down.

So do that when the user has selected HDR image as output, but not when the
user has selected one of the common "old" formats limited to the 0-1 range.

I'd like to hear your thoughts on Slime's other posts
(the one posted Fri, 27 Aug 2004 16:19:34 -0400).

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Slime wrote:
> [...]
> 
> Gamma correction should always be done as the last thing in a renderer's
> output. In fact, if the user plans to do anything more with the output
> image, then they should turn off gamma correction, do whatever
> postprocessing they want, and *then* apply gamma correction. Then, when the
> image is displayed on a monitor, the gamma effects will cancel out the gamma
> correction and present the viewer with the correct image.

That's right if you use gamma correction purely for the purpose it is 
intended for (i.e. for compensating the monitor gamma).  A lot of people 
however use it for artistic purposes just like the clipping.  It is 
still fairly common for example to design scenes to show up correctly on 
a certain monitor without gamma correction.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

andrel wrote:
> I do agree with Christoph that some solution has to be found to
> counter this unwanted phenomenon. I find his response more
> constructive than Thorston's.

Hehe, agreed, but that's hardly news...

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Christoph Hormann wrote:
> That's right if you use gamma correction purely for the purpose it is
> intended for (i.e. for compensating the monitor gamma).  A lot of
> people however use it for artistic purposes just like the clipping.

But that's not what it is intended for! This is not the sole reason we are
facing the jagged edge problem now, is it? If *anything* is an "artistic
trick" then using gamma correction for the purpose you describe would surely
be it!

Slime made a good and well-worded suggestion on how the process could work,
and your only reply is to point out that it would break scenes where gamma
correction is used incorrectly (or as an artistic trick at least)?

This goes completely against your own argument in other posts... I don't get
it.

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message