> In fact it's the opposite: the color values that they access are the
> clipped and gamma corrected values (in the "in" array) and they can
> request and access the unclipped ungamma-corrected values (in the Data
> structure if they set the right flag). And the final output is not gamma
> corrected which ensures a different result on different machines. I
> think that the opposite should be true: the "in" array should contain
> the pre-gamma, pre-clipping values and gamma correction should occur
> after the post processing.

You have a very good point.

Post processing filters were (as you describe) created to primarily use the
clipped, gamma corrected, and the non-clipped values are available.  But, as
you point out, the non-clipped values are NOT the ones that are passed
through the filter chain, so if you put in a filter that uses those values,
it will nullify any filters that happend before it.  The filter would
probably want to gamma-correct and clip those values after it is done with
them.  The real problem is that those filters would not "play nice" with
other filters.

So, I agree that, IDEALLY, filters should work primarily on the non-clipped,
non-gamma values and then gamma correction and clipping should happen last
and automatically.  HOWEVER, this causes a problem:

Sometimes (maybe always), the raw float values are NOT anti-aliased.  I
tried to anti-alias them, but adaptive anti-aliasing uses such crazy code
that it was not at all trivial and I gave up.  It could be done, but I
didn't want to put the time into it, and I didn't quite know how I'd go
about anti-aliasing (or not) things like depth, normal, and the object
index.

I figured I'd go with what I had and it would have to be "good enough" until
POV 4.  That is, unless someone else wants to "fix" it (but please try not
to make the code TOO messy).

-Nathan

Post a reply to this message