clipka schrieb:
> I just compiled the official beta.35a sources for Linux, to find that 
> there's something whacky about it; here's how it renders the sample 
> scenes "abyss.pov" and "fractals2.pov".

I managed to track down the issue to the output file gamma correction, 
which uses the following pattern for all of the offending file formats:

     encodedR = (unsigned char) floor (
         clip(powf(r, gamma), 0.0f, 1.0f) * 255.0
     );

(and correspondingly for G and B channels)

Obviously, this goes bonkers when r is negative (which is physically 
nonsense, but may happen with some exotic scene constructs) and gamma 
does not happen to be an integer value. In such cases, the result of the 
powf() function will be #NaN ("Not a Number").

Apparently, something in the expression

     (unsigned char) floor (clip(#NaN, 0.0f, 1.0f) * 255.0)

is compiler-dependent, with Microsoft and Intel compilers returning 0 
but g++ returning 255.

The proper solution would be to clip to positive values /before/ 
gamma-adjusting; given that any number smaller than 1.0f raised to 
whatever positive power will give a result smaller than 1.0f, while any 
number greater than 1.0f raised to whatever positive power will give a 
result greater than 1.0f, the clipping to a maximum value of 1.0f can 
also safely be performed before gamma-adjusting. Thus, the offending 
statements should be changed to the following pattern:

     encodedR = (unsigned char) floor (
         powf(clip(r, 0.0f, 1.0f), gamma) * 255.0
     );

(I guess similar issues can be found in the HDR and PPM output code, but 
those don't kick in because the file formats store linear data by 
definition or convention, and therefore no gamma correction is performed 
there with the scenes I used for testing.)

I'll file a bug report.

Post a reply to this message