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