When you render a pic with povray, the color range can be more than 0-1
an d it gets clipped before saving. Then in order for a scene to look
the same way on all machines, the image is gamma corrected according to
assumed_gamma and display gamma. But the post process filters act after
this clipping and gamma correction. I don't think this is a good idea, I
think the post processing should occur before color clipping and gamma
correction. I know that a post process filter can access the original
un-clipped, un-gamma corrected values, but:

* Since the post processing occurs after gamma-correction, the results
are machine dependant which defeats the whole purpose of assumed_gamma
and display gamma;
* If a post process filter needs to act on the unclipped values, it will
have to ignore any filter that runs before itself, whereas if the post
processing worked with the unclipped values and a filter needed the
clipped values, it could clip them itself. The reverse is not true;
* In the same order of idea, if the user wants some clipping and/or
gamma correction to be done before other filters, it's easy for him to
specify them explicitely (I think they already exist anyway) so that
means more choice and flexibility.

	What does everybody think?


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

<Jer### [at] enstfr> wrote:

> 	What does everybody think?

How about an raw_colors filter that would take the raw color values and 
write them to the current image? This would be backwards compatible.
However, I expected the colors to be unclipped and unmodified, and this 
sounds like a bug...maybe gamma correction should be turned off 
completely for the post_processed version of the image(you get the 
straight output of the filters instead of a gamma corrected version, 
this would allow you to do your own correction in the filters.). The 
filters get unclipped, unprocessed values and the only thing done after 
processing is to clip the values to fit in the file.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote...

> However, I expected the colors to be unclipped and unmodified, and this
> sounds like a bug...

AFAIK, the float values that the post process filters access are in fact
pre-gamma and pre-clipping.  At least that's what I intended when I wrote
the code... and a quick look at the source code (search for
"Assign_PP_Data") confirms this.  (Assign_PP_Data, which copies all the
post-processing data to the appropriate array, is done between Trace or
Trace_Primary_Ray and the corresponding calls to clip_colour and
gamma_correct.)

Post processing filters also have access to the gamma-corrected, clipped
values (these are the values that most filter writers use).

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> AFAIK, the float values that the post process filters access are in fact
> pre-gamma and pre-clipping.  At least that's what I intended when I wrote
> the code... and a quick look at the source code (search for
> "Assign_PP_Data") confirms this.  (Assign_PP_Data, which copies all the
> post-processing data to the appropriate array, is done between Trace or
> Trace_Primary_Ray and the corresponding calls to clip_colour and
> gamma_correct.)
> 
> Post processing filters also have access to the gamma-corrected, clipped
> values (these are the values that most filter writers use).
> 
	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.


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

> 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