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'm running openSUSE 11.2 (x86_64) on an AMD Phenom 9650 2.3GHz system 
with 6GB RAM; POV-Ray 3.7.0.beta.35a was compiled with g++ 4.4.

The symptoms can be seen with TGA and JPG output as well, but not with 
HDR or PPM, so obviously the error is somewhere in the image file 
generation.

It appears that in the offending cases, color components with a zero 
value are "upped" to a value of 255 instead (or maybe "downed" to -1, 
hard to tell).

Strange thing is:

- Only a few images seem to be affected, and even in the affected images 
not all parts suffer the effect (for instance, when turning all lights 
off in abyss.pov, the parts that are pink now will show up white, while 
everything else will be pitch black except for a few white specks).

- The symptom did not occur with previous betas I had compiled with 
Intel's icpc compiler; however, I had to recompile those recently, and 
couldn't get the icpc to do the job anymore for unknown reasons, so 
recompiled them with g++ 4.4 as well, and now I see the same symptom 
with those as well.

- The symptom does not occur on Windows.

Can anyone confirm? This error looks really freakish to me at present.

Post a reply to this message

Attachments:
Download 'abyss.pov.png' (366 KB) Download 'fractals2.pov.png' (882 KB)

Preview of image 'abyss.pov.png'

Preview of image 'fractals2.pov.png'

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

Le 23/03/2010 15:24, clipka nous fit lire :

> 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.

Have you tried to remove "-fastmath" (sp?) from the compilation option ?
It might help on the issue.

Post a reply to this message

Le_Forgeron schrieb:

> Have you tried to remove "-fastmath" (sp?) from the compilation option ?
> It might help on the issue.

I'm not in need for any workarounds; the code needs fixing anyway, so 
that's the way I'll be going. Thanks for sharing the idea though.

Post a reply to this message