Am 28.01.2011 10:44, schrieb Jaime Vives Piqueres:

>  From OpenEXR technical documentation:
>
> ----------------------------------------------------------------------
> half numbers have 1 sign bit, 5 exponent bits, and 10 mantissa bits. The
> interpretation of the sign, exponent and mantissa is analogous to
> IEEE-754 floating-point numbers. half supports normalized and
> denormalized numbers, infinities and NANs (Not A Number). The range of


> ----------------------------------------------------------------------
>
> I checked a POV-Ray generated .exr with IC, and seems it uses the "half"
> format... so, I suppose this means we can use 65000 as a safe value for
> POV-Ray generated .exr files?

POV-Ray OpenEXR output does indeed uses the 16-bit so-called "half 
precision" IEEE-754 floating point format (which BTW has made it into 
the IEEE 754 standard by now, as of IEEE 754-2008).

A value of 65000 is not sufficient though. As the half precision float 
format (which BTW actually is part of the IEEE-754 standard by now) uses 
5 exponent bits and an exponent bias of 15, with exponent codes 0 and 31 
being reserved for special values, and the 10-bit mantissa representing 
only the fractional part of a value >= 1.0, the largest representable 
number is actually just a bit below 2.0*(2^15) = 65536.0. (Also note 
that the lowest "normalized" value is 1.0*(2^-14), and the precision of 
"subnormal" values is 1*(2^-24).)

To minimize loss of precision due to rounding errors, you should use a 
power-of-2 factor, so 65536 should be the value to go for.


There's actually no need to worry about precision errors for small 
values. For all computations, POV-Ray internally uses at least the 
"float" C++ data type, which on most machines is implemented as the 
32-bit "single precision" IEEE 754 floating point type with 8 exponent 
bits and an exponent bias of 127 - allowing to represent exponents in 
the range from -126 to +127 (again, exponent codes 0 and 255 are 
reserved) - and a mantissa of 23 (+1) bits; this has the following 
implications:

- For "normalized" half precision values, a division by 65536 boils down 
to nothing more than subtracting 16 from the exponent value, giving a 
resulting exponent of no less than -30, well within the float range (the 
mantissa value will be left unchanged).

- For "subnormal" half precision values, a division by 65536 boils down 
to shifting the mantissa N bits to the left so that the most significant 
non-zero bit ends up in the implied 24th mantissa bit, and setting the 
exponent value to -14-N, giving a resulting exponent value of no less 
than -37, still well within the limits of the IEEE 754 single-precision 
float format.

In either case, the internal data format is more than sufficient to 
represent the resulting value range at full precision, and with a 
power-of-2 divisor you'll not even get any rounding problems.

Post a reply to this message