Re: [Openexr-devel] Some problem about half

[Richard Addison-Wood]

Hi Yan,

I didn't see any other responses to this, so I'll comment.

You have encountered the limits of floating point representation. These 
kind of limits also happen with floats and doubles,  but it is much more 
pronounced for halfs.

The half data type uses 16 bits to represent a floating point number 
with limited range and precision.  This allows for the representation of 
65535 different values.

There is a balance between representing some fractional values while 
also representing a usable range of values.

Integral values with magnitudes from 0 to 2048 can be represented 
exactly.  (Actually, magnitudes between 0 and 1024 can be represented 
with more precision, as described later, but the magnitudes from 1024 to 
2048 are only with steps of 1.)

Even integral values with magnitudes from 2050 to 4096 can be 
represented exactly (but no odd values).

Multiples of 4 with magnitudes from 4100 to 8192 can be represented exactly.

That pattern progresses similarly for multiples of 8, 16, and 32. So, 
multiples of 32 with magnitudes from 32800 to 65504 can be represented 
exactly.  Note that 65536 cannot be represented.  The next largest 
magnitude beyond 65504 that can be presented is infinity.

Going the opposite directly in precision, multiples of 0.5 with 
magnitudes from 0.0 to 1024.0 can be represented exactly.

Multiples of 0.25 with magnitudes from 0.0 to 512.0 can be represented 
exactly.

That pattern progresses similarly for multiples of 1/8, 1/16, 1/32, ..., 
1/8388608, and 1/16777216.

Multiples of 1/2048 with magnitudes from 0.0 to 1.0 can be represented 
exactly.

Multiples of 1/16777216 with magnitudes from 0 to 1/16384 can be 
represented exactly.  And those are the most closely spaced values that 
can be represented.

All together there are 31 different patterns for those powers of 2. Each 
pattern handles 1024 values (when we account for how my description has 
overlaps).  There is also a sign bit, representations for positive and 
negative infinity, and 2046 different Not-A-Number representations.  
That covers the 65536 different values that can be represented.

In general, you would use a half for storage when you want to be compact 
and the range and precision of values is suitable.

For intermediate calculations, you would want to use a floating point 
representation with more precision and a larger range, such as a float.

--
Richard Addison-Wood

On 20/01/15 22:47, Yan wrote:
> Dear all,
>
> I have a problem about half.
> I read the *.exr image using the openexr library 2.2.0, and then copy the
> value from the array.
> But, when I compare the original and the copy value, I found that they are
> not the same!
> This situation occurs when the 16-bit unsigned integer of half is bigger
> than 31744.
>
> Here is my c++ code and the output is "no.":
> half tempR;
> tempR = rUncompressionPixels[0][0];
> if(rUncompressionPixels[0][0] != tempR)
> {
>         cout << "no." << endl;
> }
>
> Does there have any update of openexr library to solve this problem?
>
> Yan 2015.01.20
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [Openexr-devel] Some problem about half
>
>
>
>
> Date: 
>
> Tue, 20 Jan 2015 10:02:51 +0000
>
>
>
>
> User-agent: 
>
> Loom/3.14 (http://gmane.org/)
>
>
>
>
> Dear all,
>
> In fact, the range have the problem is from 31754~32767 and 64513~65535.
>
> Yan 2015.01.20
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
> --- End Message ---