Re: [Openexr-devel] Floating Point Questions (and a C Question)

[peterh]

HI Vincent,

To vaguely answer your questions:

1. ImfCRgbaFile.h provides a C interface to the library - it is not a complete interface to all C++ functionality, however. For more advanced interaction with OpenEXR in a C application, it might be worth implementing the functionality required in a custom C++ layer, then providing an interface to that layer in C. The same applies to other languages, too.

2. From experience, half float is good enough for storing images without perceptual loss, performing better than 12 bit log encoded data.
 Bear in mind that half float has higher precision/dynamic range than almost all cameras can capture and that almost all displays can handle. So intuitively it's "good enough", at least for storing images. Generally image processing applications convert from half to full float for all calculations, only converting back to half float to store or display final images. There's a memory hit by storing intermediate results as 32 bit float, but it is faster and less lossy. Continuously rounding calculations to half float precision will quite quickly produce perceptual errors.

Non-image data is a different story. half float may not be enough to store depth data, UV maps, motion vectors etc. The best approach is to see what happens!

All floating point operations are 'lossy' in that they have finite precision - it's just that 16 bit half float is more lossy than 32 bit float, and much more lossy than 64 bit float. In the same way that sometimes double floats are required to maintain required precision or to represent very large or small numbers, there are times that half float is sufficient for the required precision and data range.

Of course, OpenEXR can support storing data as 32 bit float as well, so you can use that for cases which need more precision.

3. I don't follow where the -1 to 1 comes from. Image data can have values which are arbitrarily large, by using a HDR image combiner or in CG. (In fact explosions, lightning etc, rendered in CG can easily max out the range of half). Negative values are often present, too - it can happen due to black level subtraction in cameras, film base subtraction in film scanning, or gamut mapping operations. So the full range of half float is used, even for 'regular' image data.

However, in short: yes, the lossless compression schemes do take advantage of the fact that a run of values in a channel are likely to be in a similar range, and use that to help the compression when that is the case. For details see the implementation of the compress and uncompress functions in https://github.com/openexr/openexr/blob/master/OpenEXR/IlmImf/ImfZipCompressor.cpp

Peter

On 2013-04-27 13:43, Vincent Olivier wrote:

Hi guys,

 

I have three questions for (any of) you:

 

1. What happened to the "C" linking interface that is mentioned in the documentation? I couldn't find any C-compatible export in the header files. Did I miss something?
2. Since most programming languages do not have a "half" primitive, it is fair to say that since most pixel arithmetics are done in 32-bit single precision "float" space, the 16-bit half-precision storage is actually lossy? If so, are there any studies on how (human- or machine-) perceptually lossy this is, in practice, both for in-camera images and computer-generated ones?
3. Am I right to say that only half of the exponent field of the variable precision number representation will ever be used since a valid channel pixel value ranges from -1 to 1? If so, is that handled by the lossless compression schemes?

 

I might be completely off with all of this, but theses are the questions that stick after some reading of the documentation and the code.

 

Thanks!

 

Vincent

_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel