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