Hi Steve,
On 6/18/2013 8:50 AM, Steve Strobel wrote:
But judging by the description of OpenEXR, I think it is truly 16-bit
internally. http://www.openexr.com/about.html says, "ILM decided to
develop a new HDR file format with 16-bit floating-point color
component values. Since the IEEE-754 floating-point specification does
not define a 16-bit format, ILM created the "half" format. Half values
have 1 sign bit, 5 exponent bits, and 10 mantissa bits...The half
format supports denormalized numbers, positive and negative
infinities, and NaNs. It is identical to the half data type in
NVIDIA's Cg graphics language, allowing a developer to process values
from an OpenEXR image directly on current NVIDIA GPUs such as the
GeForce FX family."
All that it says here is that it can represent the sentinel types of
IEEE floating-point numbers. It doesn't state that they're doing the
calculation using integer instructions. And this being ILM they probably
don't do much with processors that don't have hardware floating point,
especially since they mention NVIDIA Cg as a platform they are
interested in. You should look at the source if you have time, but I
would guess they are NOT using integer instructions.
I was thinking that a very high precision software float library would
probably be most appropriate for that, as it would tend to give the
same output even if the order of operations (and any resulting
rounding/truncation) changed. I haven't looked for such a
high-precision library.
I think what we actually would need here is not floating point but
Bignum. Bignum uses two integer values to represent numbers as a ratio.
So, unlike floating point, it can represent 1/3 exactly. Some
implementations use arbitrary-length integers. As far as I can tell,
this is the only type that will return the same answer reliably on all
platforms. Making this work with C++ operator overloading would be
interesting, you might want to explicitly cast some constants like this:
one_third = (my_type)1 / (my_type)3;
to make sure their value stays the same across platforms. This will
elide out when the normal floating type is in use.
Bignum would be useful for testing only. It's not for speed. Also, it is
less accurate to test non-production code than the version actually in
use, but I see the reason for doing so given what David's tests are now.
Thanks
Bruce
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
