Which free software could acquire 48 bits color depth pict..

External Since: Dec 21, 2005 Posts: 448

Steve wrote:
>
>On 18 Nov 2008 05:30:16 GMT, rfischer.TakeThisOut@sonic.net (Ray Fischer) wrote:
>
>>Steve wrote:
>>> rfischer.TakeThisOut@sonic.net (Ray Fischer) wrote:
>>>>Steve wrote:
>>
>>>>> It has 8 bits of exponent and 1 bit of sign. You can infer all
>>>>>the bits you want but if they can't be "flipped" in a calculation then
>>>>>they are not useful if you want to represent the full range of
>>>>>available numbers.
>>>>
>>>>But IEEE floating point doesn't do the math in just 23 bits. It
>>>>actually does it at least 26 bits and then normalizes and rounds to
>>>>24 bits. The leading 1-bit is dropped and the remaining 23 bits of
>>>>fraction are stored in the result.
>>>
>>>That depends on the implementation.
>>
>>IEEE floating point defines a standard implementation.
>>
>>> For instance, a PowerPC with an
>>>Altivec may do FP math different than an Intel Xeon which may be
>>>different than an old 80x86 with a math coprocessor which may be
>>>different than....
>>
>>If it's IEEE floating point then the rounding is done a standard way.
>>Most hardware these days sticks pretty close to the standard.
>
>And yet different machines give different results even with the same
>code compiled on the same version of a compiler.

I know why.

Do you?

--
Ray Fischer
rfischer.TakeThisOut@sonic.net

External Since: Dec 21, 2005 Posts: 448

Eric Stevens wrote:
>On 18 Nov 2008 05:31:27 GMT, rfischer DeleteThis @sonic.net (Ray Fischer) wrote:
>
>>Eric Stevens wrote:
>>>On 17 Nov 2008 09:44:04 GMT, rfischer DeleteThis @sonic.net (Ray Fischer) wrote:
>>>
>>>>Steve wrote:
>>>>>
>>>>>On Mon, 17 Nov 2008 16:45:50 +1300, Eric Stevens
>>>>> wrote:
>>>>>
>>>>>>When an image is manipulated in any way the new RGB/CMYK data is the
>>>>>>product of the computer's calculating engine. It is at this point that
>>>>>>the accuracy of the calculations become important.
>>>>>
>>>>>*IF* the math engine is implemented correctly (and that's a big if
>>>>>since many are not) then you only need one more significant bit to
>>>>>carry through the calculations than you have in the data.
>>>>>
>>>>>The 32 bit IEEE 754 floating point format that most computers use only
>>>>>has 24 significant bits. But one of them is a sign bit. Since image
>>>>>data is unsigned, you can only represent 23 bit integer image data.
>>>>
>>>>Not strictly true. Normalized floating point numbers actually do have
>>>>24 bits of fraction plus 8 bits of exponent plus 1 bit of sign. It's
>>>>done by inferring a leading one in the fraction that isn't actually
>>>>represented.
>>>>
>>>>>Which means you can use 32 bit floating point math on 22 bit or less
>>>>>unsigned integer image data if you want to keep your precision through
>>>>>multiple calculations.
>>>>
>>>>In practice chaining floating point operations while maintaining
>>>>precision is really hard. If it's possible. Integer math is
>>>>preferable almost always.
>>>
>>>Why do you think I wrote that " ... an 8-bit floating point algorithm
>>>to emulate an 80 bit APU is likely to incorporate an accumulation of
>>>rounding off errors"?
>>
>>Because you don't know what you're writing about. The fact that it may
>>be an 8-bit processor makes no difference at all. ALL floating point
>>math is subject to accumulated errors.
>
>... and its always the same amount of error?

The amount of error has nothing at all to do with whether the
processor is 8-bit or 64-bit. It has everything to do with the
specific implemenation of the floating point routines and the ordering
of operations done by the compiler.

--
Ray Fischer
rfischer DeleteThis @sonic.net