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