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

[Florian Kainz]

Some comments in addition to Peter's:

Question 2:

Converting from 32-bit to 16-bit floating-point is lossy.  The maximum
quantization error, abs((f-x)/x), where x is the number you are trying
to represent, and f is the floating-point number closest to x, increases
from about 6e-8 to 5e-4.  In addition, 16-bit numbers have a smaller
range than 32-bit numbers.  Converting any value greater than 65504 to
16-bit half produces an infinity.

The 16-bit halfs are a proper subset of the 32-bit floats.  This means
that for any given half value, h, float(h) == h, and half(float(h)) == h.
In other words, converting from half to float and back is lossless.

If 16-bit float numbers are used to encode RGB values that are approximately
proportional to luminance, then the encoding is perceptually lossless.
Depending on viewing conditions, a just noticable difference (the smallest
change that a viewer can detect) is between 0.5% and 2% of the absolute
value.  The quantization step (the smallest possible non-zero difference
between two half values) is 0.1%, or five to twenty times smaller than
what a human can detect.  To humans 16-bit floating-point RGB values appear
to be continuous, with no visible quantization.

Question 3:

The range of 16-bit half numbers goes from -65504 to +65504.  Half uses
a single bit to determine if a number is positive or negative.  There are
31744 finite positive negative half values (1024 of the bit 32768 patterns
where the sign bit indicates "positive" represent infinity or not-a-number).
About half of the positive half values are greater than 1.0 and the other
half are less than 1.0.

All lossless compression schemes in OpenEXR take advantage of patterns in
the pixel data.  If the range of pixel values is limited, for example, by
restricting values to the range from 0.0 to 1.0, then the data will be
compressed more, but the effect will not be very large.  Limiting pixels
to a zero-to-one range effectively turns 16-bit pixels into 14-bit values,
so you should expect no more than about 12% space savings.  Other
characteristics of the pixel data, for example, how noisy or grainy an
image is, or whether there are large blank regions in it, will have a
much greater effect on how much space is saved by lossless compression.

Hope this helps,

Florian


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