(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

On 1/23/22 18:57, William F Pokorny wrote:
...
> 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.
...

I forgot to mention, should you run into one of these exr files with 
values too large for POV-Ray's current exr reader, you can use 
converters to get to an hdr file.

I was able to use: 'iconvert sunflowers_4k.exr sunflowers_4k.hdr'

The openimageio-tools based tooling is able to handle the >2^16 channel 
values and appears to correctly convert to 'workable' hdr files(a)(b).

Bill P.

(a) - An attempt to use incovert from full float encoding to half float 
ran and looks OK external to POV-Ray in that the values are reduced to 
what fits in a half float. However, on attempting to use the half float 
form HDRI, I still had the speckling problem - though the signature of 
the speckles was somewhat different. Not sure what's happening there.

(b) - The hdr format supports less precision and dynamic range than exr 
files, so, it's a non-ideal work around.

Post a reply to this message