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

Steve wrote:
> rfischer.RemoveThis@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.

--
Ray Fischer
rfischer.RemoveThis@sonic.net
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

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.

--
Ray Fischer
rfischer DeleteThis @sonic.net
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

Eric Stevens wrote:
>On 17 Nov 2008 09:47:17 GMT, rfischer DeleteThis @sonic.net (Ray Fischer) wrote:
>
>>Eric Stevens wrote:
>>> rfischer DeleteThis @sonic.net (Ray Fischer) wrote:
>>>>Eric Stevens wrote:
>>>>> rfischer DeleteThis @sonic.net (Ray Fischer) wrote:
>>>>>>Floyd L. Davidson wrote:
>>
>>>>>>>Regardless, PS can work with images in 8, 16 or 32 bit
>>>>>>>per channel *color*. That is not the math precision.
>>>>>>
>>>>>>If there's 32-bits to be processed with a math operation then
>>>>>>it's the math precision.
>>>>>
>>>>>Not necessarily so.
>>>>
>>>>When not?
>>>
>>>How many bits does a math processor need to handle for it to be able
>>>to deal with the Encyclopaedia Brittanica?
>>
>>What "math processor"? "Deal with" in what way?
>>
>>Your question makes a couple of incorrect assumptions.
>>1) That's there is a "math processor" that is different from the CPU.
>>2) That the processing needs to be related to a "math processor".
>
>Jeez! You must be young!
>
>Don't you remember when you were able to buy maths coprocessors to
>speed up up your PC? As you say, it is now built into the CPU but it
>is still there.

Now try and catch up to the 21st century.

A "math processor" is only some silicon to do the same calculations
that can be done in software except faster. Your insistence on
treating it like some special component is ... outdated.

>See http://en.wikipedia.org/wiki/Intel_8087
>
>http://en.wikipedia.org/wiki/Motorola_68881

Ancient history.

--
Ray Fischer
rfischer DeleteThis @sonic.net
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

On 18 Nov 2008 05:26:37 GMT, rfischer.DeleteThis@sonic.net (Ray Fischer) wrote:

>Eric Stevens wrote:
>>On 17 Nov 2008 09:38:29 GMT, rfischer.DeleteThis@sonic.net (Ray Fischer) wrote:
>>
>>>Eric Stevens wrote:
>>>> floyd.DeleteThis@apaflo.com (Floyd L. Davidson) wrote:
>>>>>Eric Stevens wrote:
>>>>>>On 17 Nov 2008 01:26:21 GMT, rfischer.DeleteThis@sonic.net (Ray Fischer) wrote:
>>>>>>>
>>>>>>>And I would like to point out that the MINIMUM precision the PS allows
>>>>>>>is 24 bits, or 8 bits per channel. And the fact that one can print
>>>>>>>16-bit/channel images doesn't mean that the device provides anywhere
>>>>>>>near that big a range of colors.
>>>>>>
>>>>>>People seem to be becoming confused. Whether a computer is an 8, 16,
>>>>>>32, 64 or 80 bit machine is important from the point of view of the
>>>>>>accuracy of the calculations its calculating engine is asked to carry
>>>>>>out.
>>>>>
>>>>>An 8 bit computer can have the same precision that an 80
>>>>>bit machine has. It will likely also take about 10
>>>>>times as long to make the same calculation at that
>>>>>precision...
>>>>>
>>>>>The difference is speed, not precision.
>>>>
>>>>True to a point. But an 8-bit floating point algorithm to emulate an
>>>>80 bit APU is likely to incorporate an accumulation of rounding off
>>>>errors.
>>>
>>>Nope. It will produce the exact same result.
>>
>>All I can say is that that wasn't my experience about 1980ish.
>
>I still have an Apple //e that does IEEE floating point using it's
>8-bit processor. What can be done in silicon can be done the same in
>software, just slower. In fact all the major chip makers use
>emulators that simulate the working of the chip in software in order
>to make sure that it works correctly.

I don't know about the Apple //e but are you really trying to say that
all the software floating point emulators had the same accuracy as an
equivalent hardware APU?



Eric Stevens
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

On 18 Nov 2008 05:28:37 GMT, rfischer RemoveThis @sonic.net (Ray Fischer) wrote:

>Eric Stevens wrote:
>>On 17 Nov 2008 18:41:00 GMT, rfischer RemoveThis @sonic.net (Ray Fischer) wrote:
>>
>>>J. Clarke wrote:
>>>>Ray Fischer wrote:
>>>>> Eric Stevens wrote:
>>>>>> rfischer RemoveThis @sonic.net (Ray Fischer) wrote:
>>>>>>> Eric Stevens wrote:
>>>>>
>>>>>>>> People seem to be becoming confused. Whether a computer is an 8,
>>>>>>>> 16, 32, 64 or 80 bit machine is important from the point of view
>>>>>>>> of the accuracy of the calculations its calculating engine is
>>>>>>>> asked to carry out.
>>>>>>>
>>>>>>> No it isn't. Even an 8-bit processor can do 128-bit math.
>>>>>>>
>>>>>>>> This is NOT the same as the number of bits used in the RGB/CMYK
>>>>>>>> data channels used to describe the images.
>>>>>>>
>>>>>>> What do you think the math is working on?
>>>>>>
>>>>>> Of course the math is working on the individual data channels but
>>>>>> there is no need for number of bits in the channels to match the
>>>>>> number of bits in the arithmetic processors.
>>>>>
>>>>> Sigh. You guys have very little idea how computers do math.
>>>>>
>>>>> Did you know that a lot of image processing these days is done by
>>>>> the
>>>>> graphics processor in the video card? Did you know that SIMD
>>>>> instructions are used to process multiple chunks of data
>>>>> concurrently?
>>>>
>>>>Computers "do math" in whatever way the programmer decides.
>>>
>>>Sigh. You guys have very little idea how computers do math.
>>
>>I am an engineer with all that that entails with an interest in
>>numerical computation.
>
>What kind of engineer?

Mechanical. I've been using Finite Element calculations since the year
dot and accumulated errors have always been a primary concern.
>
>> I encountered my first computer in 1960 and
>>have been working with them ever since. Its more than 40 years since I
>>wrote programs directly in machine code and probably 30 years since I
>>used assembler. From the outset I wrote programs in Fortran and I was
>>an early user of C .... .
>
>Been there - done that. In addition I've got about 6 yers worth of
>university education and decades of experience as an actual software
>engineer.
>
>> My programs worked which seems to make a
>>nonsense of your claim that I have very little idea of how computers
>>do math.
>
>You don't need to know ANYTHING about how computers do math in order
>to write code.

You do when the programs are large and complex.



Eric Stevens
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

On 18 Nov 2008 05:30:16 GMT, rfischer.RemoveThis@sonic.net (Ray Fischer) wrote:

>Steve wrote:
>> rfischer.RemoveThis@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.

I've been involved in this since before the IEEE standard and in any
case sticking 'pretty close' is not good enough.



Eric Stevens
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

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?



Eric Stevens
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

On 18 Nov 2008 06:32:23 GMT, rfischer RemoveThis @sonic.net (Ray Fischer) wrote:

>Eric Stevens wrote:
>>On 17 Nov 2008 09:47:17 GMT, rfischer RemoveThis @sonic.net (Ray Fischer) wrote:
>>
>>>Eric Stevens wrote:
>>>> rfischer RemoveThis @sonic.net (Ray Fischer) wrote:
>>>>>Eric Stevens wrote:
>>>>>> rfischer RemoveThis @sonic.net (Ray Fischer) wrote:
>>>>>>>Floyd L. Davidson wrote:
>>>
>>>>>>>>Regardless, PS can work with images in 8, 16 or 32 bit
>>>>>>>>per channel *color*. That is not the math precision.
>>>>>>>
>>>>>>>If there's 32-bits to be processed with a math operation then
>>>>>>>it's the math precision.
>>>>>>
>>>>>>Not necessarily so.
>>>>>
>>>>>When not?
>>>>
>>>>How many bits does a math processor need to handle for it to be able
>>>>to deal with the Encyclopaedia Brittanica?
>>>
>>>What "math processor"? "Deal with" in what way?
>>>
>>>Your question makes a couple of incorrect assumptions.
>>>1) That's there is a "math processor" that is different from the CPU.
>>>2) That the processing needs to be related to a "math processor".
>>
>>Jeez! You must be young!
>>
>>Don't you remember when you were able to buy maths coprocessors to
>>speed up up your PC? As you say, it is now built into the CPU but it
>>is still there.
>
>Now try and catch up to the 21st century.
>
>A "math processor" is only some silicon to do the same calculations
>that can be done in software except faster. Your insistence on
>treating it like some special component is ... outdated.
>
>>See http://en.wikipedia.org/wiki/Intel_8087
>>
>>http://en.wikipedia.org/wiki/Motorola_68881
>
>Ancient history.

Its still a maths coprocessor, even when you build it into the same
silicon as the CPU.



Eric Stevens
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

Eric Stevens wrote:
> On Sun, 16 Nov 2008 19:41:54 -0900, floyd.DeleteThis@apaflo.com (Floyd L.
> Davidson) wrote:
>
>> Eric Stevens wrote:
>>> On 17 Nov 2008 01:26:21 GMT, rfischer.DeleteThis@sonic.net (Ray Fischer) wrote:
>>>> And I would like to point out that the MINIMUM precision the PS allows
>>>> is 24 bits, or 8 bits per channel. And the fact that one can print
>>>> 16-bit/channel images doesn't mean that the device provides anywhere
>>>> near that big a range of colors.
>>> People seem to be becoming confused. Whether a computer is an 8, 16,
>>> 32, 64 or 80 bit machine is important from the point of view of the
>>> accuracy of the calculations its calculating engine is asked to carry
>>> out.
>> An 8 bit computer can have the same precision that an 80
>> bit machine has. It will likely also take about 10
>> times as long to make the same calculation at that
>> precision...
>>
>> The difference is speed, not precision.
>
> True to a point. But an 8-bit floating point algorithm to emulate an
> 80 bit APU is likely to incorporate an accumulation of rounding off
> errors.

Indeed. One would need to go back down the underlying
integer implementation of floating point
and code carefully. Knuth outlines the details.

You certainly couldn't (usefully) "layer up"
floating point, as you say.

BugBear
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

Paul Furman wrote:
> bugbear wrote:
>> Guilbert STABILO wrote:
>>> => Do you know any free software or plugin which could work with 48
>>> bits pictures acquired from a scanner ?
>>
>> Cinepaint
>>
>> http://www.cinepaint.org/
>
> Ah... that makes sense for b&w I guess...
>
> "Top Reasons to Use CinePaint
>
> 4. Gallery-quality printing. B&W photographs have only one color
> channel and degrade quickly when manipulated as 8-bit images. CinePaint
> has higher fidelity and offers a 16-bit printing path to the print-head
> using GutenPrint."
>

It's 16 bit (atcually up-to-32 bit) per CHANNEL,
so it works just dandy for colour too.

It's just particularly critical for B&W.

BugBear
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

Ray Fischer wrote:
> Eric Stevens wrote:
>> On 17 Nov 2008 09:38:29 GMT, rfischer.DeleteThis@sonic.net (Ray Fischer)
>> wrote:
>>
>>> Eric Stevens wrote:
>>>> floyd.DeleteThis@apaflo.com (Floyd L. Davidson) wrote:
>>>>> Eric Stevens wrote:
>>>>>> On 17 Nov 2008 01:26:21 GMT, rfischer.DeleteThis@sonic.net (Ray Fischer)
>>>>>> wrote:
>>>>>>>
>>>>>>> And I would like to point out that the MINIMUM precision the
>>>>>>> PS
>>>>>>> allows is 24 bits, or 8 bits per channel. And the fact that
>>>>>>> one can print 16-bit/channel images doesn't mean that the
>>>>>>> device provides anywhere near that big a range of colors.
>>>>>>
>>>>>> People seem to be becoming confused. Whether a computer is an
>>>>>> 8,
>>>>>> 16, 32, 64 or 80 bit machine is important from the point of
>>>>>> view
>>>>>> of the accuracy of the calculations its calculating engine is
>>>>>> asked to carry out.
>>>>>
>>>>> An 8 bit computer can have the same precision that an 80
>>>>> bit machine has. It will likely also take about 10
>>>>> times as long to make the same calculation at that
>>>>> precision...
>>>>>
>>>>> The difference is speed, not precision.
>>>>
>>>> True to a point. But an 8-bit floating point algorithm to emulate
>>>> an 80 bit APU is likely to incorporate an accumulation of
>>>> rounding
>>>> off errors.
>>>
>>> Nope. It will produce the exact same result.
>>
>> All I can say is that that wasn't my experience about 1980ish.
>
> I still have an Apple //e that does IEEE floating point using it's
> 8-bit processor. What can be done in silicon can be done the same
> in
> software, just slower. In fact all the major chip makers use
> emulators that simulate the working of the chip in software in order
> to make sure that it works correctly.

If I understand what he was saying correctly then he's talking about
using 8-bit floating point instructions to construct an 80-bit
floating point routine. Seems to me like doing a tonsillectomy
through the rectum but if all you've got is a hammer . . .

I do wonder what machine he has encountered though that actually _has_
8-bit floating point instructions.

--
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

Eric Stevens wrote:
>On 18 Nov 2008 05:28:37 GMT, rfischer DeleteThis @sonic.net (Ray Fischer) wrote:
>>You don't need to know ANYTHING about how computers do math in order
>>to write code.

That _VERY_ MUCH_ depends on what code you write and the application
area.

>You do when the programs are large and complex.

Actually no, it's not a matter of size of complexity.
But you do need a good understanding whenever numerics are involved,
beginning with simple matters like finance and bookkeeping.
After all, it's not the missing million that is drivng the accountant up
the walls (that one is easy to find and correct) but the missing penny
caused by accumulated rounding errors because the programmer had no clue
about computer numerics.

jue
 >> Stay informed about: Which free software could acquire 48 bits color depth pict.. 

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. Hell, I've even seen
different machines give different results even with the same
executable code. It's rarer than the first case, which happens a lot.

Steve
 >> Stay informed about: Which free software could acquire 48 bits color depth pict..