In POV-Ray 3.5 antialiasing was done after clipping the color to the range
0...1. In POV-Ray 3.6 this has been changed so that antialiasing is done
before clipping.

Before 3.6 this issue had been discussed here in the groups on several
occasions and there were both quite some people who found the 3.5 behavior
correct and quite some who found it incorrect.

The commonly mentioned advantage of the new 3.6 behavior is that starfields
with sub-pixel sized (but very bright) stars will now show up.

The disadvantage is that all objects or textures with very bright (or
brightly lit) colors will now have jagged edges even though AA is turned on.

This can be demonstrated by this simple scene:
// +w160 +h120 +a0.3
sphere {z, 0.5 pigment {rgb 10} finish {ambient 1 diffuse 0}}

One might argue that the sphere doesn't need to be that bright, but if it's
used as a light-source in a radiosity scene, it might actually need to be
that bright.

One of the advanced sample scenes that comes with both POV-Ray 3.5 and 3.6
"bwstripe.pov" is seriously ill affected by the new behavior, and looks
really bad, since it was highly dependent on the color clipping being done
prior to the antialiasing.

Also, in povray.binaries.images, several people have seen the bad effects of
the new behavior. On an overexposured white table the objects have jagged
edges, and in another picture with some laser beams, those beams are awfully
jagged.

Despite how bad these jagged edges look, some people argue that they are
*desirable* because they are *realistic* since real cameras work the same
way. I don't think this makes sense. In real cameras overexposure makes a
glow that is often much larger than a pixel. This is the job of focal blur
(which *should* be done prior to clipping), not antialiasing.

Anyway, my point is, making a new feature is fine as long as it is optional,
but making it at the cost of braking an old feature is very disrespectful to
those who liked the old feature and found it to be the current behavior.

I hope the new antialiasing behavior will either be changed back or be made
optional very soon...

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

Workaroud:

Render it with 4xSize and scale it down with your favourite Graphics 
Program :) <Just kiddin>

Good point, i didn't realize it until i checked back with the bwstripes.pov

I fully support the optional handling

Arne

Rune schrieb:
> In POV-Ray 3.5 antialiasing was done after clipping the color to the range
> 0...1. In POV-Ray 3.6 this has been changed so that antialiasing is done
> before clipping.
> 
> Before 3.6 this issue had been discussed here in the groups on several
> occasions and there were both quite some people who found the 3.5 behavior
> correct and quite some who found it incorrect.
> 
> The commonly mentioned advantage of the new 3.6 behavior is that starfields
> with sub-pixel sized (but very bright) stars will now show up.
> 
> The disadvantage is that all objects or textures with very bright (or
> brightly lit) colors will now have jagged edges even though AA is turned on.
> 
> This can be demonstrated by this simple scene:
> // +w160 +h120 +a0.3
> sphere {z, 0.5 pigment {rgb 10} finish {ambient 1 diffuse 0}}
> 
> One might argue that the sphere doesn't need to be that bright, but if it's
> used as a light-source in a radiosity scene, it might actually need to be
> that bright.
> 
> One of the advanced sample scenes that comes with both POV-Ray 3.5 and 3.6
> "bwstripe.pov" is seriously ill affected by the new behavior, and looks
> really bad, since it was highly dependent on the color clipping being done
> prior to the antialiasing.
> 
> Also, in povray.binaries.images, several people have seen the bad effects of
> the new behavior. On an overexposured white table the objects have jagged
> edges, and in another picture with some laser beams, those beams are awfully
> jagged.
> 
> Despite how bad these jagged edges look, some people argue that they are
> *desirable* because they are *realistic* since real cameras work the same
> way. I don't think this makes sense. In real cameras overexposure makes a
> glow that is often much larger than a pixel. This is the job of focal blur
> (which *should* be done prior to clipping), not antialiasing.
> 
> Anyway, my point is, making a new feature is fine as long as it is optional,
> but making it at the cost of braking an old feature is very disrespectful to
> those who liked the old feature and found it to be the current behavior.
> 
> I hope the new antialiasing behavior will either be changed back or be made
> optional very soon...
> 
> Rune

Post a reply to this message

Rune <run### [at] runevisioncom> wrote:
> Despite how bad these jagged edges look, some people argue that they are
> *desirable* because they are *realistic* since real cameras work the same
> way. I don't think this makes sense. In real cameras overexposure makes a
> glow that is often much larger than a pixel. This is the job of focal blur
> (which *should* be done prior to clipping), not antialiasing.

  Incorrect.

  Focal blur is not an antialiasing/color bleeding algorithm. Focal blur
is a depth-blurring algorithm which is quite independent and has little
or nothing to do with antialiasing or color bleeding. (Focal blur has
the *side-effect* of smoothing edges even in the sharpest parts of the
image, but its true purpose is not to be an antialiasing algorithm.)

  You are correct in that the physically correct interpretation of
overbright areas in the image is that their brightness should "bleed"
to nearby pixels (the amount of bleeding depending on the brightness and
the distance of the nearby pixel).
  In practice this means that a very bright object will have a soft glow
around it (the intensity and size of the glow depending on the brightness
of the object).

  If this photographic phenomenon should be simulated, it would be the task
of an algorithm developed for that specific task. Focal blurring has nothing
to do with that. The soft glow of bright objects has nothing to do with
whether the image is sharp or blurred (it's not a question of focus; it's
a question of light hitting the film; when the light is very bright it
will spread in the film).

  The option to clipped antialiasing should be an unclipped color bleeding
algorithm (which is performed besides the unclipped antialiasing).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
>   You are correct in that the physically correct interpretation of
> overbright areas in the image is that their brightness should "bleed"
> to nearby pixels

>   If this photographic phenomenon should be simulated, it would be
> the task of an algorithm developed for that specific task.

Okay, I agree about that.

But we also agree that clipping prior to antialiasing should be possible, as
it has always been prior to POV-Ray 3.6?

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

Warp wrote:
> Focal blur has the *side-effect* of smoothing edges even in the sharpest
parts of the image

Actually this is not true.

Images with focal blur have jagged edges at the exact distance of the focal
point. Antialiasing could take care of that, but for some reason I never
understood, antialiasing and focal blur are mutually exclusive in POV-Ray.

But this is off-topic for this thread.

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

Rune <run### [at] runevisioncom> wrote:
> Images with focal blur have jagged edges at the exact distance of the focal
> point.

  Can you show me a concrete example?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> Rune <run### [at] runevisioncom> wrote:
>> Images with focal blur have jagged edges at the exact distance of
>> the focal point.
>
>   Can you show me a concrete example?

I'm sorry, no. I remember reading it somewhere and I remember it as though I
experienced it myself too, but it's a long time ago, and I can't reproduce
it now. I take it back.

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

In article <412f1e37$1@news.povray.org> , "Rune" <run### [at] runevisioncom>
wrote:

> Anyway, my point is, making a new feature is fine as long as it is optional,
> but making it at the cost of braking an old feature is very disrespectful to
> those who liked the old feature and found it to be the current behavior.
>
> I hope the new antialiasing behavior will either be changed back or be made
> optional very soon...

Keep dreaming.  Frankly, as there will be complains no matter what we do, it
certainly isn't going to be a reason to change anything.  It is that simple.
Get over it and fix your scenes!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Rune wrote:
> In POV-Ray 3.5 antialiasing was done after clipping the color to the range
> 0...1. In POV-Ray 3.6 this has been changed so that antialiasing is done
> before clipping.

That is not quite correct, POV-Ray 3.6 had clipping/gamma correction 
before antialiasing with non-adaptive aa (which contained a bug causing 
trouble with gamma correction).  3.6.1 fixed this bug by moving the 
clipping to the very end of the whole process (i.e. before the file 
writing) which among other things makes the HDR output much cleaner.

The whole issue has really been discussed a lot in the past i think but 
limiting it to the clipping and where to apply it does not really cover 
the whole issue sufficiently.  The problem occurs with all kind of 
non-linear tone mapping functions, no matter if gamma correction, 
clipping, film exposure (in MegaPOV) or anything else.  Since it is very 
common (and will become even more common with HDR output) to post 
process these tone mapping effects applying them before the antialiasing 
step is not always an option.

An idea i already drafted some time ago to allow efficient antialiasing 
with HDR scenes was to use an estimation of the final tone mapping used 
(the simplest would be an exponential function like in the film exposure 
feature) for the color averaging in the antialiasing code and to 
afterwards apply the inverse tone mapping function to restore the HDR 
color values.  The problem about the clipping in this concern is that it 
in not invertible - once clipped you can't restore the old color values.

I think clipping has only two purposes:

- to make the values fit into the range of image file formats.  This 
should always be done directly before file writing (and is now done this 
way in POV-Ray 3.6.1).
- to serve as an artistic/technical element (in fact the clipping itself 
is not the artistic element but the use of colors brighter than <1,1,1> 
for pure white).  What you complain about not being possible any more is 
exactly this kind of trick.  An additional clipping option might be 
useful now but it should be clear that this would be an additional 
artistic feature (just like reflection exponent and radiosity 
max_sample) and by default it should be turned off.

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:
> - to serve as an artistic/technical element (in fact the clipping
> itself is not the artistic element but the use of colors brighter
> than <1,1,1> for pure white).  What you complain about not being
> possible any more is exactly this kind of trick.

If I have a pure radiosity scene illuminated by a bright object representing
the sun, how is it an "artistic element" to have the sun be very bright? Why
do you refer to it as a "trick"? I think it is a standard use of POV-Ray to
have objects brighter than <1,1,1>. And it is undesirable to have a standard
use of the program result in jagged edges when antialiasing is turned on.

> An additional clipping option might be useful now but it should be clear
that this
> would be an additional artistic feature (just like reflection
> exponent and radiosity max_sample) and by default it should be turned
> off.

If you think that avoiding jagged edges in (for example) a scene with a
realistic setup of light intensities and textures is an "artistic feature"
the be it so, but I still think it's important.

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

Thorsten Froehlich wrote:
> Keep dreaming.

I *am* dreaming - of a POV-Ray where certain developers wouldn't have so
much of a "we know better, so mind your own business" kind of attitude.

> Frankly, as there will be complains no matter what we
> do, it certainly isn't going to be a reason to change anything.

Who would complain if there feature was optional?

> It is that simple. Get over it and fix your scenes!

Fix them how exactly?

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

Rune wrote:
> 
> If I have a pure radiosity scene illuminated by a bright object representing
> the sun, how is it an "artistic element" to have the sun be very bright? Why
> do you refer to it as a "trick"? I think it is a standard use of POV-Ray to
> have objects brighter than <1,1,1>. And it is undesirable to have a standard
> use of the program result in jagged edges when antialiasing is turned on.

I have the impression you did not read completely what i wrote.  When 
you have very bright parts in a scene it would be *wrong* to clip them 
because as long as the file format used for writing the image supports 
it it should be unclipped in the file.  The jagged edges you observe are 
part of a larger problem (the non-linear tone mapping) and just clipping 
  the color values at an arbitrary value before antialiasing does not 
solve this problem (it would just be an artistic trick).

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:
> I have the impression you did not read completely what i wrote.
> When you have very bright parts in a scene it would be *wrong* to clip
them

First of all, there is no objective right or wrong. What you think is wrong
might be right to me, and possibly a lot of other users.

> because as long as the file format used for writing the image supports
> it it should be unclipped in the file.

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.

> The jagged edges you observe are part of a larger problem
> (the non-linear tone mapping) and just clipping the color
> values at an arbitrary value

Not arbitrary.

> before antialiasing does not solve this problem (it would
> just be an artistic trick).

And I suppose that this thing that you call a trick, and which many users
want, and which make many images look better is *wrong*? Why?

And when I define the problem as the presence of jagged edges, then why is
the discussed clipping not a solution to this problem, when it does indeed
remove the jagged edges?

Mind you, for me a "solution" is to use POV-Ray 3.5 instead of 3.6. It's
just not a very good solution. You can't say what's a solution and what
isn't to a problem that I have defined.

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

>>Images with focal blur have jagged edges at the exact distance of the focal
>>point.
>   Can you show me a concrete example?

	Warp - it seems you were not convinced by the examples I presented
somewhere else (although very specific, I admit, but the point is to show
there is _indeed_ a problem in the sharpest parts).

	I also agree with what Rune says about this particular point.  I may
post a small patch to 3.6.1 which re-enables antialiasing method 2 together
with focal-blur, for people to judge the effect on their own scenes.

	- NC

Post a reply to this message

Nicolas Calimet wrote:
> Warp - it seems you were not convinced by the examples I presented
> somewhere else (although very specific, I admit, but the point is to
> show there is _indeed_ a problem in the sharpest parts).
>
> I also agree with what Rune says about this particular point.  I may
> post a small patch to 3.6.1 which re-enables antialiasing method 2
> together with focal-blur, for people to judge the effect on their own
> scenes.

I'd try it out! :) (If a windows binary will be available.)

While you're at it, could you re-enable pre-AA color clipping too? ;)

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'd try it out! :) (If a windows binary will be available.)

	Well I should write the patch first (I did it long ago for
POV-Ray 3.1g, so I need some time to adapt it to 3.6.1 and do some
checks) and was only thinking to release the patched sources.
	Okay I'll try to make some linux and windows binaries, but
the latter will most likely be compiled with mingw and without GUI.

	Since I also have other things to do at the moment (yet POV-
code related), please don't expect to get this patch soon.

> While you're at it, could you re-enable pre-AA color clipping too? ;)

	I won't; as you said yourself the focal-blur stuff is off-topic,
so will be this small patch  ;-)

	- NC

Post a reply to this message

Rune wrote:
> 
> First of all, there is no objective right or wrong. What you think is wrong
> might be right to me, and possibly a lot of other users.

You can understand words differently but 'wrong' in the sense i use it 
for has nothing to with something being wrong and right *for someone* in 
the sense of being useful or not useful.  It is about being wrong under 
criteria of consistent and transparent design.  You have failed to bring 
up any arguments why applying tone mapping before antialiasing is more 
consistent than doing it before file writing.

>>because as long as the file format used for writing the image supports
>>it it should be unclipped in the file.
> 
> 
> 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.

> And I suppose that this thing that you call a trick, and which many users
> want, and which make many images look better is *wrong*? Why?
> 
> And when I define the problem as the presence of jagged edges, then why is
> the discussed clipping not a solution to this problem, when it does indeed
> remove the jagged edges?

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.

Don't get me wrong, i never said the clipping isn't a useful trick for 
scene design, citing from my first reply:

>> An additional clipping option might be 
>> useful now but it should be clear that this would be an additional 
>> artistic feature (just like reflection exponent and radiosity 
>> max_sample) and by default it should be turned off.

but as said it is just a trick and should no way be applied by default.

> Mind you, for me a "solution" is to use POV-Ray 3.5 instead of 3.6. It's
> just not a very good solution. You can't say what's a solution and what
> isn't to a problem that I have defined.

If you think this solution has a future i don't mind.  But i think 
trying to understand the reasons why this is changed and why this change 
is not bad per se and working out a solution that does not revert this 
change would be a much more elegant approach.

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:
> You have failed to bring up any arguments why applying tone
> mapping before antialiasing is more consistent than doing
> it before file writing.

> i think trying to understand the reasons why this is
> changed and why this change is not bad per se and working
> out a solution that does not revert this change would be a
> much more elegant approach.

Oh, but any solution that produce results that to my untrained eye will look
like the AA from POV-Ray 3.5 will be fine by me. I don't feel strongly about
*how* the problem of the jagged edges are solved, just that they are solved
some way or another.

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?

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

In article <412f3c83$1@news.povray.org> , "Rune" <run### [at] runevisioncom>
wrote:

>> Keep dreaming.
>
> I *am* dreaming - of a POV-Ray where certain developers wouldn't have so
> much of a "we know better, so mind your own business" kind of attitude.

It is not like somebody in the team woke up one day and said: Hey, what am I
going to do today?  Ah, yes, I know, I am going to "break" anti-aliasing to
screw up Rune's scenes.

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

>> Frankly, as there will be complains no matter what we
>> do, it certainly isn't going to be a reason to change anything.
>
> Who would complain if there feature was optional?

Because it is not a feature, it always was a bug.  Unlike some companies,
the POV-Ray tries to not sell you bugs as features.  We corrected the bug.
It was requested many times in the past to fix it sooner rather than later.

>> It is that simple. Get over it and fix your scenes!
>
> Fix them how exactly?

That is simple: You assume POV-Ray has some "magic" exposure control.  The
scenes you are rendering would not be visible to a human eye in reality.
You eye will adjust to the bight visible part and the rest will appear
darker.  POV-Ray could do this for you by keeping all unclipped pixel value
and than normalise them to 1.0 based on some approximation (there is no
generally unique algorithm to do this "right"), but so far no such feature
has been implemented.

So what you need to do is rather trivial: Learn to understand that POV-Ray
is not like a camera, it is like a window.  When you look out, your eyes
would adjust and you would not get over-exposure.  As outlined, POV-Ray
cannot do this, so to what you would when it is to bright somewhere: Turn
down your light.

Yes, the dark parts of the scene will not be visible, but they are not
visible in the real world either.  And what you will get is more/better
realism!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> So what you need to do is rather trivial: Learn to understand that
> POV-Ray is not like a camera, it is like a window.  When you look
> out, your eyes would adjust and you would not get over-exposure.  As
> outlined, POV-Ray cannot do this, so to what you would when it is to
> bright somewhere: Turn down your light.
>
> Yes, the dark parts of the scene will not be visible, but they are not
> visible in the real world either.  And what you will get is
> more/better realism!

No. The human eye has a much wider dynamic range than what a monitor (or a
photograph) can represent. The real world and POV-Ray scenes alike can have
a huge dynamic range, while a photograph and an image format (the ones
currently supported by POV-Ray) alike can only represent a limited dynamic
range. Thus, rendering an image is much more like capturing a photograph
than it is like looking out the window.

Besides, your statement represents a very very subjective opinion on how
POV-Ray should be used, and lots of great artwork made with POV-Ray couldn't
have been made had this advise been followed.

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

> 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

Rune 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?

I explained the quite in depth in my previous replies.  If anything is 
unclear about what i wrote please ask.  If not you will find the 
explanations there.

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

> 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.

Which is great when you're rendering an HDR image, and really ugly/useless
when you're rendering in a format with a range from 0 to 1. The range that
values are clipped to should be the same as the range that the output format
actually supports.

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

Post a reply to this message

In article <412f9568@news.povray.org> , "Slime" <fak### [at] emailaddress> wrote:

>> 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.

That may well be your opinion, but that does not make you statement correct.
Prior to POV-Ray 3.6 what you got when using anti-aliasing was a fancy
averaged blur of every pixel, not different from scaling down an image
rendered without anti-aliasing.  That is not all what anti-aliasing is
about.  This certainly is a nice side effect of an incorrect implementation.

In reality small bright objects do not disappear, ever.  To the contrary.

If you want this behavior, render with twice the resolution and scale down
using some fancy algorithm in your favorite image editing program.  That
gets you the effect you so much desire, no matter how incorrect it is.

Either way, I suggest to end this fruitless discussion.  POV-Ray will not be
damaged the way you ask, no matter how much noise you produce.  The decision
stands as is because it corrects a bug.  If you do not like this correction,
you are free to continue to use POV-Ray 3.5.  Nobody is forcing you to use
POV-Ray 3.6 after all.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

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 admit that a part of me agrees that the clipping is kind of an ugly,
non-mathematically-correct thing to do. But the fact is that it must be done
at some point when the image formats that we're outputting to require it. I
do like the idea of not clipping until just before output because in a way
it *feels* like the right thing to do - not introducing the limitation until
it's actually necessary.

Nonetheless, this "feeling" that clipping before sampling is kind of ugly is
not entirely relevant. I've "felt" a lot in the past that my mathematical
results were right or wrong, and I've often been incorrect.

Clipping *at all* is mathematically incorrect. If a sphere has color rgb 10,
then values of 10 should be written to the output. But obviously that can't
be done if the output format doesn't support it.

So we have to live with the clipping one way or another. We have, at the
point of admitting this, already introduced a certain level of mathematical
incorrectness. Our goal should be to do it in the most useful way.

I have seen no evidence that clipping after averaging samples is any more
"mathematically correct" than clipping beforehand. As I just said, both ways
are slightly incorrect, but we have no choice, we must clip at some point.
What I'm saying now is that there is no evidence that I've seen that one way
is *more correct* than the other.

However, I have seen evidence that clipping after averaging is much less
useful.

If anyone has a concrete reason why clipping after averaging is more
mathematically correct, I'm open to hearing it. If one has already been
mentioned, please point me to it. But I don't believe I have seen a concrete
reason.

In summary, my argument here is that neither method is more mathematically
correct than the other, but the 3.5 method was most certainly more useful.

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

Post a reply to this message

Christoph Hormann wrote:
> I explained the quite in depth in my previous replies.  If anything is
> unclear about what i wrote please ask.

Well, you've said a lot of things, and it's difficult for me to know what
exactly is the core of the problem, but I suppose I just need to take it
quote by quote.

> That is not quite correct, POV-Ray 3.6 had clipping/gamma correction
> before antialiasing with non-adaptive aa (which contained a bug causing
> trouble with gamma correction).  3.6.1 fixed this bug by moving the
> clipping to the very end of the whole process

Gamma correction needed to be moved to after the AA, but it is not clear
here why clipping needed to be moved to after AA too.

> Since it is very common (and will become even more common with HDR
> output) to post process these tone mapping effects applying them
> before the antialiasing step is not always an option.

Why is it not an option to clip to the 0-1 range prior to AA in those cases
where the output format is also restricted to the 0-1 range?

> You have failed to bring up any arguments why applying tone
> mapping before antialiasing is more consistent than doing it before file
writing.

You write tone mapping here, but tone mapping is many things as you've
explained yourself. I have never said that *all* tone mapping should be done
prior to AA, only that clipping to the same range as the output format
supports (which may be infinity) should be done before AA. And my argument
for doing this is to avoid the jagged edges. What was your counter-argument
again?

> 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.

Do you mean that support for incorrect use of gamma correction has higher
priority than the possibility of using bright objects without getting jagged
edges?

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

> 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.

As Rune pointed out, if people are using gamma correction for reasons other
than gamma correction, then they're using the wrong tool for the job and
should not be surprised if it doesn't have the correct effect.

If someone wants to create an artistic effect that changes the values of
colors that the camera sees, then they should do this in their scene file.
One way would be to place an object in front of the camera which somehow
filters the color values.

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

Post a reply to this message

> > The previous behavior was correct; the current behavior is broken.
>
> That may well be your opinion, but that does not make you statement
correct.

Of course not, which is why I added many paragraphs after that statement to
show why it was correct. It was merely my thesis. =)

> That may well be your opinion, but that does not make you statement
correct.
> Prior to POV-Ray 3.6 what you got when using anti-aliasing was a fancy
> averaged blur of every pixel, not different from scaling down an image
> rendered without anti-aliasing.  That is not all what anti-aliasing is
> about.

I agree that the method through which antialiasing is applied isn't
relevant - whether it's created by rendering a large image and scaling it
down, or through any other method. What *is* relevant is the effect.
Anti-aliasing is, by definition (and by the meaning of the word itself), an
effect to remove aliasing. POV-Ray 3.6's anti-aliasing does not remove
aliasing. Why then is it even called anti-aliasing? It's not doing its job.

> In reality small bright objects do not disappear, ever.  To the contrary.

I wish I understood more about how the human eye works so that I could
better respond to that statement. However, it is important to recognize
that, in the case of stars, a large part of the fact that we can see them is
due to light scattering through the atmosphere as it reaches our eyes. I'm
not sure exactly how tiny the average star would be, but it's probably
smaller than it actually appears. Some stars *are* so far away that the
human eye can't see them. This is probably due to the fact that there is a
limit to the number of photons travelling away from the stars, and with
stars that are far away enough the chances of some of those photons hitting
our eyes is tiny. But all of this has to do with effects that POV-Ray does
not, by default, simulate. Scattering media could be used to make tiny
distant light sources with tiny bright looks_like spheres visible, thus
recreating the appearance of actual stars in the real world. I'm willing to
bet that, if our eyes had resolution comparable to 1024x768, and there were
a really tiny bright object very far away, unaffected by things like light
scattering, we wouldn't be able to see it - no matter how sophisticated our
brain's "anti-aliasing" might be. I think it's very likely that the only
reason we can see far away bright objects is because our eyes have a very
high resolution. Not that our eyes can really be compared to a monitor in
such a simple way.

My point here is that the fact that small bright objects are visible in real
life has nothing to do with samples of light being averaged together, one of
which is much brighter than the others. It's due to a number of other
factors, and POV-Ray 3.6's anti-aliasing is a poor attempt at simulating
those factors with a single calculation.

It could also be pointed out that even with POV-Ray 3.6's antialiasing, many
small bright objects *do* disappear: those which are not hit by the primary
rays, so that supersampling does not occur. 3.6's attempt at simulating the
visibility of distant bright objects is therefore not even very accurate,
and people have to create an exceedingly high number of tiny bright spots in
order to make a much smaller number of pixels white to simulate stars.

None of this addresses the fact that the anti-aliasing is there to remove
aliasing, and not to make tiny bright objects visible. That's not its job.
Its job is to remove aliasing, and it's not doing that.

By the way: tiny, *not* bright objects never disappear either. But they are
not visible in any renderer's output.

> Either way, I suggest to end this fruitless discussion.

You only see the discussion as fruitless because you believe that you are
correct and the people making the "noise" are incorrect. If this discussion
is more than a matter of opinion - that is, if it is based on what is
"correct" and what is "incorrect" - then there is no reason for it to end
until everyone understands what is correct and why. I *am* influenced by log
ic, and if I am presented with a flawless argument that shows me that I am
incorrect, I will stand corrected. I trust you feel the same.

> The decision
> stands as is because it corrects a bug.

I have not seen any evidence that 3.5's anti-aliasing was buggy. It did its
job. If there was a bug with it, then there must be a concrete explanation
for that bug, beyond "it was incorrect." *Why* was it incorrect? As I've
shown, "because it didn't show tiny bright objects" is not an entirely valid
reason. However, "because it doesn't remove aliasing" seems like a very good
reason why 3.6's anti-aliasing is incorrect.

> If you do not like this correction,
> you are free to continue to use POV-Ray 3.5.  Nobody is forcing you to use
> POV-Ray 3.6 after all.

I only argue this point because I want POV-Ray to be the best it can; it is
not for any personal agenda.

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

Post a reply to this message

> I may
> post a small patch to 3.6.1 which re-enables antialiasing method 2 together
> with focal-blur

	The patch is ready and working -- was actually quite easy to port it
from 3.1g to 3.6.1.  However, before publishing I'd like to investigate
something which relates to adaptive antialiasing (method 2) alone, i.e.
w/o using focal blur.
	I'll try to post something, including linux/windows binaries, over
the week-end.

	- NC

Post a reply to this message

I hardly use the built-in antialiasing. I use the focal blur trick instead, 
although it doesn't work if the aperture is too small.

Post a reply to this message

Sounds weird to me that the atmosphere scattering photons causes us to see 
stars that would be invisible otherwise. The atmosphere merely blurs 
providing it reaches our retinas.

Post a reply to this message

In article <412fef84$1@news.povray.org> , "Eli" <eli### [at] jehoelnet> wrote:

> Sounds weird to me that the atmosphere scattering photons causes us to see
> stars that would be invisible otherwise. The atmosphere merely blurs
> providing it reaches our retinas.

The ability of the human eye or a real camera to see infinitely small but
very bright objects has nothing to do the atmosphere.  It has to do with
sampling an area compared to sampling points.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Eli wrote:

> Sounds weird to me that the atmosphere scattering photons causes us to see 
> stars that would be invisible otherwise. The atmosphere merely blurs 
> providing it reaches our retinas. 
> 
Correct, astronauts do see stars.

The human eye is able to detect a single photons (if adapted
to darkness). Starlight of the faintest stars is single photons just
often enough to see them.

Post a reply to this message

> The ability of the human eye or a real camera to see infinitely small but
> very bright objects has nothing to do the atmosphere.  It has to do with
> sampling an area compared to sampling points.

Fair enough. But when the human eye does this, it is able to accurately
depict the shape of the object.

In the case of a star, the difference may not be noticable between a
pixel-sized square on your computer screen and the shape of a star in the
sky. As I've said, the 3.6 behavior is useful for those who want to make
stars visible, which is why I'm OK with having the behavior as an option.

But in the case of large bright objects, the image that POV-Ray is providing
looks nothing like what the human eye would see. The human eye would not see
a jagged edge where there is a smooth one, regardless of the brightness of
the object. One's brain would use their eyes to seek out the edge of the
object and portray it as it appears: smooth. POV-Ray 3.6 is not emulating
this (more useful) behavior, in favor of creating an arguably aesthetic
effect in the single case of starfields.

You're saying that the eye has a high enough "resolution" that, if it saw a
star unaffected by atmospheric scattering or anything, despite the fact that
the star would be incredibly tiny, the eye would be able to see it. However,
the eye would display it at the size that it was. POV-Ray 3.6 is taking the
tiny object and blowing it up to the size of a pixel, *by letting it affect
the samples taken around it*. It is also doing this for the edges of larger
objects, allowing shapes that should be smaller than a pixel (like a tiny
triangle cut off of the edge of a sphere) to be blown up to the size of a
full pixel, causing aliasing.

Returning to your statement "It has to do with sampling an area compared to
sampling points," the primary difference is this: the human eye does not
take the samples of that area and average them together and then display the
average value as the value for the whole area. It takes them individually
and displays all objects at the correct size and shape. Obviously POV-Ray
can't do this in its output, since it is limited to pixels. Therefore it
must make a compromise: it can't produce exactly what the human eye would
see, so it must do the best it can to display something that *appears*
correct to the human eye. The compromise in 3.5 appeared correct. The
compromise in 3.6 does not.

The primary usage, purpose, and original intent of anti-aliasing is to
remove aliasing. 3.6's anti-aliasing is failing at this.

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

Post a reply to this message

run### [at] runevisioncom news:412f1e37$1@news.povray.org

> The disadvantage is that all objects or textures with very bright (or
> brightly lit) colors will now have jagged edges even though AA is
> turned on. 

Imho this *is* the correct behaviour in most cases - if only *10 times 
brighter object occupies 1/10 (or more) of pixel - enitre pixel should be 
white. It should be gray only if object occupies less then 0.1 of pixel 
area IMHO.

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

"Slime" <fak### [at] emailaddress> wrote in message
news:4130e456@news.povray.org...
> Returning to your statement "It has to do with sampling an area compared
to
> sampling points," the primary difference is this: the human eye does not
> take the samples of that area and average them together and then display
the
> average value as the value for the whole area. It takes them individually
> and displays all objects at the correct size and shape. Obviously POV-Ray
> can't do this in its output, since it is limited to pixels. Therefore it
> must make a compromise: it can't produce exactly what the human eye would
> see, so it must do the best it can to display something that *appears*
> correct to the human eye. The compromise in 3.5 appeared correct. The
> compromise in 3.6 does not.
>

Jumping into the middle of this discussion:

One point to remember is that human eyes are a set of sensing instruments
in the service of the brain.
Brains process sensory input and do a lot of "anti-aliasing".
The image you perceive is a brain-processed image that is heavily influenced
by memory, interpolation, pattern recognition, imagination plus a little
'objective
data'.

"The map is not the territory." -   Korzybski

Post a reply to this message

> I *am* dreaming - of a POV-Ray where certain developers wouldn't have so
> much of a "we know better, so mind your own business" kind of attitude.

I apologise for the tone of Thorsten's reply. Please understand that we all
get a bit frustrated sometimes. Working on a raytracer as complicated as ours
is a bit of a balancing act - fixing one problem sometimes introduces others
and no matter what we do folks will be unhappy ;-(

We do what we can and sometimes it just doesn't work out the way folks want.
As for this problem we will discuss it internally to see if there is a way
around it (no promises).

-- Chris

Post a reply to this message

Chris Cason wrote:

>>I *am* dreaming - of a POV-Ray where certain developers wouldn't have so
>>much of a "we know better, so mind your own business" kind of attitude.
> 
> 
> I apologise for the tone of Thorsten's reply. 
You do not have to, (nearly) everbody here has seen how Thorsten
replies in general. I (and again most of us here I guess) assume
that he is just a bit unlucky in the way he responds and is probably
a nice guy when you meet him IRL.
> Please understand that we all get a bit frustrated sometimes. 
we do.
> Working on a raytracer as complicated as ours
> is a bit of a balancing act - fixing one problem sometimes introduces others
> and no matter what we do folks will be unhappy ;-(
I think it is a beautiful example of how fixing one bug introduces
unwanted side effects elsewhere. Do you mind if I use it as an example?
> 
> We do what we can and sometimes it just doesn't work out the way folks want.
> As for this problem we will discuss it internally to see if there is a way
> around it (no promises).
Thanx in advance.

Post a reply to this message

Chris Cason wrote:
> I apologise for the tone of Thorsten's reply. Please understand that
> we all get a bit frustrated sometimes. Working on a raytracer as
> complicated as ours is a bit of a balancing act - fixing one problem
> sometimes introduces others and no matter what we do folks will be
> unhappy ;-(

Yeah, this conversation should be seen in the light that developers and
users alike can both get frustrated, and we're all human.

I truly appreciate the Team's effort in continuously improving POV-Ray, and
even my reply to Thorsten should not be seen as a personal attack, but just
as a comment to the tone of the specific reply he posted here.

> We do what we can and sometimes it just doesn't work out the way
> folks want. As for this problem we will discuss it internally to see
> if there is a way around it (no promises).

That's very nice to hear! :)

Best regards,

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" <fak### [at] emailaddress> wrote:
> > The ability of the human eye or a real camera to see infinitely small but
> > very bright objects has nothing to do the atmosphere.  It has to do with
> > sampling an area compared to sampling points.
>
> Fair enough. But when the human eye does this, it is able to accurately
> depict the shape of the object.

This is a complicated issue, but the end result is that the eye can't do
this. Badly worded and simplified explanation follows.

> You're saying that the eye has a high enough "resolution" that, if it saw a
> star unaffected by atmospheric scattering or anything, despite the fact that
> the star would be incredibly tiny, the eye would be able to see it.

Imagine the surface of the retina divided into a regular grid of pixels.
Although the eye's grid of "pixels" is far from regular, each pixel has
area - each pixel is sensitive to light over a *non-zero* region of the
retina. A photon landing *anywhere* within a "pixel" will be detected. A
source such as a star whose photons all end up within one pixel will light
up only that pixel. No other information will be received about that
source. The star's true image could be circular, square, shaped like a hoop
or anything you like, but as far as the eye is concerned it is shaped like
a pixel, and the pixel is 200 times bigger than the star's true image. The
eye cannot preserve detail it can't resolve. This pixel is then the
smallest unit that the eye deals in. So,

> However the eye would display it at the size that it was. POV-Ray 3.6 is
> taking the tiny object and blowing it up to the size of a pixel, *by letting
> it affect the samples taken around it*.

POV in this case is doing exactly what the eye would do. However, POV must
simulate a finite pixel area by taking additional samples, because a ray
has no area (ideally - I imagine there is a numerical precision issue
here). Both eye and POV are doing the same thing, except that POV is
impersonating a finite pixel area by taking extra samples. In the extreme
case, a raytracer would divide the camera field of view angles by the
number of pixels in each direction (horizontal and vertical) to get a grid
of rectangles and shoot a few hundred rays through each rectangle. That
would imitate as near as possible a finite pixel size, although it would be
closer to a digital camera's response than to that of the eye or film.

> Returning to your statement "It has to do with sampling an area compared to
> sampling points," the primary difference is this: the human eye does not
> take the samples of that area and average them together and then display the
> average value as the value for the whole area. It takes them individually
> and displays all objects at the correct size and shape. Obviously POV-Ray
> can't do this in its output, since it is limited to pixels.

Both eye and raytracer deal in pixels. In the case of the eye the pixels are
irregular in shape and distribution and are somewhat squidgey and
disgusting, but there is still no way for the eye to capture and record
detail smaller than the size of its own active regions/pixels/buckets.

This simplified explanation ignores several things, the most important of
which is the point-spread function of the eye, but the relatively low
resolution of most CG images makes this irrelevant.

> Therefore it must make a compromise: it can't produce exactly what the human
> eye would see, so it must do the best it can to display something that
> *appears* correct to the human eye. The compromise in 3.5 appeared correct.
> The compromise in 3.6 does not.

> The primary usage, purpose, and original intent of anti-aliasing is to
> remove aliasing. 3.6's anti-aliasing is failing at this.

For what it's worth I agree with the general point that effectively limiting
use of bright objects with antialiasing seems a bit harsh. Neither POV-Ray
nor any other CG package outside the most specialist are faithful
imitations of the human visual system, absent super-sampled images and
post-processing. The question then could be about what looks better. Does
anti-aliasing remove jaggies, or not? That point about work-arounds is also
a strong one in my view.

Post a reply to this message

> As for this problem we will discuss it internally to see if there is a way
> around it (no promises).

Glad to hear that! Thanks for taking the time.

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

Post a reply to this message