(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
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.
Post a reply to this message