Re: [Openexr-devel] loosing massive amount of information using openexr

[Morten Mikkelsen]

I should mention I've been able to verify Blender's OpenEXR support actually is working

correctly with 32 bit export. 

Photoshop's is busted. xNormal is locked to fp16 and so is DevIl. So don't worry Ton, Blender's all good :)

Cheers,

Morten.

On Thu, Dec 27, 2012 at 4:19 PM, Morten Mikkelsen <address@hidden> wrote:

Okay I did some more tests in photoshop cs3 (win7).

I did a clouds (perlin fractalsum noise) in 32 bit mode.

this exported as 16 bit png gives an image with 24789 unique levels.

if instead of exporting as 16 bit png I export as 32 bit openexr,

then import this image back into photoshop I get only 5625 unique levels.

The image upon import is reported to be full float 32 bit but nevertheless only very few unique levels exist.

I've checked and the openexr plugin in photoshop is indeed 6 years old.

I am wondering if older versions had a tendency to drop internally to fp16 even when not requested or something.

On Thu, Dec 27, 2012 at 2:19 PM, Morten Mikkelsen <address@hidden> wrote:

I think quite possibly that could be correct.

xnormal doesn't let you choose but it wouldn't shock me if it's using fp16.

DevIl and blender claim to be doing lossless f32 export but I think their UIs are lying to me.

I'll do some more testing in ps. Do you know of any reliable tool that will allow me to query

an openexr image? In regards to compression type and whether or not it's data was half or full floats.

Thanks,

Morten.

On Thu, Dec 27, 2012 at 2:03 PM, Bob Friesenhahn <address@hidden> wrote:

On Thu, 27 Dec 2012, Morten Mikkelsen wrote:

I am trying to use open exr for export/import of height maps.
I am exporting maps which have hundreds of thousands of unique height values.

I have tried exporting to openexr in several different existing applications such as:
xnormal, photoshop, blender and using DevIl (image library).

In all cases I end up with no more than a small handful of unique height values. Roughly 8000.
If on the other hand I export to 16 bit png then I get roughly 65000.
If I export as .raw I of course get all my hundreds of thousands of values.

I have tried all the compression options for openexr. Lossy ones as well as non lossy ones.
None of them are giving me more than roughly 8k unique heights.
I don't know which version of openexr these tools would be using though it clearly wouldn't be the most recent
version.
That being said the fact that all 4 are showing me same behavior is leading me to suspect it's a problem with
openexr lib or perhaps a former versions of openexr.

Is this a known problem with openexr?

This is likely a problem with using 'half' floats (http://en.wikipedia.org/wiki/Half-precision_floating-point_format). Half is intended for HDR values with high dynamic range, but only about 10-bits of precision for each exponent value.  10-bits of precision is common for professional video formats, and for digital intermediates (e.g. 10-bit DPX).

If the range of your data is relatively small but it uses many adjacent values, then there will be significant loss.  There is likely an advantage to scaling up your height maps so that they use more of the Half range.

Using plain integer or 24/32 bit floats would be a better solution for you.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/