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