Re: [Openexr-devel] Processing in 'half' float

[Florian Kainz]

Hi Eric,

our in-house compositing system keeps image buffers in half
format and processes the pixels using the operators in class half,
with implicit conversions to and from float.  (This may have changed
recently; there was talk about converting all internal buffers to
float to eliminate the implicit conversions, but I am not sure if
the change was ever implemented.)

The conversions are not as bad as one might think at first.  For
example, if a, b, c, and d are of type half, then the expression

    d = a * b / c;

is executed as follows:

    d = half (float (a) * float (b) / float (c));

The half-to-float conversions are cheap; each one requires only
a single table lookup.  Only the float-to-half conversion of the
result is expensive.  (It requires a table lookup plus some bit
shifting, and the code contains conditional branches.)  In addition
for operators like blur kernels or median filters the half/float
arithmetic tends to be interleaved with significant amounts of
address arithmetic.  In practice, conversions do not cause very
large amounts of overhead.

Software-only implementations of arithmetic operations on half
are possible, but as far as I can tell, there is no way to make
them faster than converting to float and back.

The current draft for a revised version of IEEE 754-1985 includes
a 16-bit binary floating-point format that is identical to half.
However, this format is only a "storage format"; implementations
have to provide only conversions between this storage format and
other, wider formats.  According to the draft, "languages permitting
computation upon storage formats should perform such computations
in wider formats."

Florian