[cairo] _cairo_color_compute_shorts fails with FPU set to single precision

[James Cloos]

>>>>> "Owen" == Owen Taylor <otaylor at redhat.com> writes:

Owen> So, you think that for 5-bit color values, a value of 31 should end
Owen> up as 247 or 248 when converted to 8-bit color values with an
Owen> intermediate floating point value.

Point taken.  I've never dealt with input values of less than 8 bit
resolution, and so didn't think of that possibility this morning....

Actually, going from < 16 bit ints to float should follow the same
pattern X uses: 8 bit data is replicated (ie multipled by 0x101) to
get to 16 bit data.  Other sizes should do the same (the replication,
not that exact multiplication, of course), and then divide by 65536.0
to get the float value.  Unless 16 bit resolution is insufficient, in
which case replicate the bit pattern into a 32 bit int and divide by
either 2.0**32 or 2.0**31, depending on signedness of the 32 bit int.

Owen> * Input values of 31/255/65535 have to map to either 1.0 -
Owen>   epsilon or 1.0.

Yes, but to the former.

Owen> * 1.0 can't produce a user-visible effect different than 1.0 - epsilon

Owen> So you might as well say that the range of the component values for
Owen> standard SRGB color values is [0.0, 1.0].

Users should be tought to think < 1.0 rather than <= 1.0.  It is more
mathematically correct -- after all, an unsigned n-bit value is really
the intersection of [0, 2^n) and Z -- and leads to better workflows
when dealing with the more interesting image conversions & corrections.

Not only can cairo make a great platform for hdr, but it is a great
way towards all apps being hdr tolerant if not hrd capable.  And that
can only improve the experience for the users.  Especially as digital
imaging (still & motion) becomes more affordable and of higher quality.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0xED7DAEA6