On 2/13/21 6:39 AM, William F Pokorny wrote:
> On 2/11/21 2:12 PM, Kenneth wrote:
...
> 
> When I write to exr or hdr I was expecting linear encoded values, but 
> this is not what I see...
> 
> To get what I wanted in the bottom row reading the exr/hdr images back 
> into POV-Ray, instead of dividing by 9.9 as I believe is correct if 
> everything linear, I had to divide by 174.125. A value which looks to 
> have been gamma corrected.
> 
...
> 
> I believe exr and hdr input and output are supposed to be linear. 

Comments in the code say this is the intent. It is not what is happening 
on write...

> 
> I tried things like File_Gamma and gamma controls, but as the docs say 
> these appeared to be ignored for exr/hdr files.

I must have done something stupid previously while trying to gamma 
correct on the read of POV-Ray written hdr/exr image files.

After looking at some code, it was apparent the read functions allowed a 
gamma spec "to handle a non-compliant file."

Comments from the code:

// Radiance HDR files store linear color values by default, so never
// convert unless the user overrides (e.g. to handle a non-compliant
// file).

// OpenEXR files store linear color values by default, so never
// convert unless the user overrides (e.g. to handle a
// non-compliant file).

When I - again - tried reading exr files with a correcting gamma of 
0.454545, I could divide incoming values by the expect 9.9 max emission 
value and normalize to the 0-1 range as expected...

POV-Ray's written hdr and exr files are not linear.

Worse,and against my assumptions that hdr and exr were 32 bit float per 
channel formats; As implemented by POV-Ray they are only really useful 
for the representation of high dynamic range images.

The hdr format where it says 32 bit apparently means 32 bits combined 
RGBE (three R,G,B 8 bit channels and an 8 bit 'shared' exponent...) The 
exr format - which I have looked at less - as implemented, looks to be 
using half floats (16 bits less the exponent) per channel. Though 
openexr supports 32bit floats per channel.

All this means these two formats are more or less useless compared to 
other 16 bit per channel formats - IF aiming to maintain the greatest 
number of significant digits and not represent dynamic range.

As to why the write output is getting gamma corrected, it's not clear to 
me at the moment. The code more or less "reads" right, but when I add 
throws to the NeutralGammaCurve functions like Encode, Decode in 
colorspace.cpp,the render doesn't crash (doesn't reach those linear 
versions) as I believe it should.

This a v3.7, v3.8 issue. These formats were not in v3.6 or prior though 
IIRC they were in megapov (v3.6 based).

Bill P.

Post a reply to this message