(Just posting my povr branch commit message here so the exr image issue 
is recorded somewhere)

Found where incoming exr files are at floats and the file has channel 
values larger than about 2^16 we end up with +inf color channel values 
internally.

This causes unavoidable speckling whenever one of these files is used 
with a sky_sphere and a ray hits a location with a +inf internal channel 
value - even if as part of a larger set of AA rays. In other words AA 
cannot fix this kind of speckling bug.

The kind of speckling changes depending upon the -ffast-math options 
being used or not. Note! The bad internal values are not correct in any 
case, nor universally clamped. Further, other problems than sky_sphere 
use might present themselves.

The hack of a fix the povr branch is adopting is two fold.

First, the addition of pre-scan code in the openexr.cpp file controlled 
by EXR_PRESCAN_PATCH. Here the +inf channel values are replaced by the 
largest valid channel values otherwise seen for each channel. This 
better than what -fno-fast-math trips some of the color space template 
code to do. But, yes it's a hack.

On adoption of the newer 3.0 OpenEXR, the right full float read support 
should be implemented so these larger values in exr HDRIs don't cause 
trouble. Aside better both read and write for full floats - in addition 
to half floats.

Second, The addition of some limit checking controlled by 
POV_PIGMENT_DEBUG was added to Compute_Pigment in pigment.cpp which 
looks for +-inf in debug builds.  This checking would catch the exr 
large value issue herein, but the thinking is we could get such values 
by other means such as bad user defined pigments or too large user 
defined color channel values.

Bill P.

Post a reply to this message