Which free software could acquire 48 bits color depth pictures from a scanner ?
Guilbert STABILO
I need to scan some old films using a 48 bits color depth (in order to keep
the quality after some graphical process).
My Canon CS5200F does it well but none of my graphical softwares can handle
48 bits picture.
The GIMP 2.6.2 translated my pictures from 48 to 24 bits.
IrfanView does the same as the GIMP (48 => 24).
I also tried XnView which is supposed to handle 48 bits pictures but when
the picture is transfered from the scanner, I get a black screen (I tried
in 24 bits and got the correct picture so this is really a color depth
problem).
I heard that the GIMP 2.6.2 was using a module called GECL which handles 48
bits pictures but I did not find any to configure/activate it : my pictures
are always handled as 24 bits picture.
I do not want to buy any graphical software because many free ones exist.
=> Do you know any free software or plugin which could work with 48 bits
pictures acquired from a scanner ?
Thanks in advance for your help.
nospam
<guilbert...@yahnomailoo.fr> wrote:
> => Do you know any free software or plugin which could work with 48 bits
> pictures acquired from a scanner ?
try the 30 day free trial of adobe photoshop cs4.
mark raif
wrote:
While not free, it's relatively inexpensive. Photoline www.photoline.com From
what I recall the free demo doesn't really expire nor cripple itself, you just
get a longer nag screen after 30 days.
If you save your scans in CMYK format then it will even properly handle 64-bit
color-depths. It's the only software that I know of that can do this. PhotoShop
still only uses 16-bit math for most of its tools and functions. Wholly
incapable of retaining all that extra data during any processing of these larger
bit-depths. This has been a thorn in the side of the "pro" world for the last 2
decades of using PhotoShop, but they all seem to ignore it and live with it.
Only recently has Adobe started to add in some 32-bit math routines to only some
of their tools and features, but by no means do all PhotoShop tools and filters
use 32-bit math. They're still working on it. Photoline has been a fully 32-bit
math platform for the last 15 years.
nospam
<mark...@privatedomain.net> wrote:
> If you save your scans in CMYK format then it will even properly handle 64-bit
> color-depths. It's the only software that I know of that can do this.
> PhotoShop
> still only uses 16-bit math for most of its tools and functions.
that's totally false.
> Wholly
> incapable of retaining all that extra data during any processing of these
> larger
> bit-depths. This has been a thorn in the side of the "pro" world for the last
> 2
> decades of using PhotoShop, but they all seem to ignore it and live with it.
> Only recently has Adobe started to add in some 32-bit math routines to only
> some
> of their tools and features, but by no means do all PhotoShop tools and
> filters
> use 32-bit math. They're still working on it. Photoline has been a fully 32-bit
> math platform for the last 15 years.
not that i believe photoline existed 15 years ago, but photoshop has
been 32 bit since it's debut in 1990.
mark raif
Photoline is at www.pl32.net
On 16 Nov 2008 17:11:01 GMT, Guilbert STABILO <guilbert...@yahnomailoo.fr>
wrote:
>Hi all,
While not free, it's relatively inexpensive. Photoline www.photoline.com From
what I recall the free demo doesn't really expire nor cripple itself, you just
get a longer nag screen after 30 days.
If you save your scans in CMYK format then it will even properly handle 64-bit
color-depths. It's the only software that I know of that can do this. PhotoShop
still only uses 16-bit math for most of its tools and functions. Wholly
NeilMolon
>In article <jql0i4do9k6o7dbk9...@4ax.com>, mark raif
><mark...@privatedomain.net> wrote:
>
>> If you save your scans in CMYK format then it will even properly handle 64-bit
>> color-depths. It's the only software that I know of that can do this.
>> PhotoShop
>> still only uses 16-bit math for most of its tools and functions.
>
>that's totally false.
I guess that's why everyone is raving about CS4 finally supporting some 32-bit
math in some of its functions.
Go back to kindergarten, would you?
nospam
<nmo...@spamblocker.org> wrote:
> I guess that's why everyone is raving about CS4 finally supporting some 32-bit
> math in some of its functions.
actually they're raving about cs4 being *64 bit*.
HEMI-Powered
du jour ...
> Hi all,
>
> I need to scan some old films using a 48 bits color depth (in
> order to keep the quality after some graphical process).
> My Canon CS5200F does it well but none of my graphical
> softwares can handle 48 bits picture.
Just curious as to why you think you need it. I obviously have not
seen your negs but I'd be surprised if any "old films" have nearly
enough dynamic range to begin to exceed 16.7 million color
capability. Besides which, isn't 48 bit color - 16 bits/channel,
along the lines of 4 bits of noise, maybe more?
> The GIMP 2.6.2 translated my pictures from 48 to 24 bits.
> IrfanView does the same as the GIMP (48 => 24).
> I also tried XnView which is supposed to handle 48 bits
> pictures but when the picture is transfered from the scanner,
> I get a black screen (I tried in 24 bits and got the correct
> picture so this is really a color depth problem).
>
> I heard that the GIMP 2.6.2 was using a module called GECL
> which handles 48 bits pictures but I did not find any to
> configure/activate it : my pictures are always handled as 24
> bits picture.
>
> I do not want to buy any graphical software because many free
> ones exist.
>
> => Do you know any free software or plugin which could work
> with 48 bits pictures acquired from a scanner ?
>
> Thanks in advance for your help.
>
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
HEMI-Powered
...
[snip]
> If you save your scans in CMYK format then it will even
> properly handle 64-bit color-depths. It's the only software
> that I know of that can do this. PhotoShop still only uses
> 16-bit math for most of its tools and functions. Wholly
> incapable of retaining all that extra data during any
> processing of these larger bit-depths. This has been a thorn
> in the side of the "pro" world for the last 2 decades of using
> PhotoShop, but they all seem to ignore it and live with it.
> Only recently has Adobe started to add in some 32-bit math
> routines to only some of their tools and features, but by no
> means do all PhotoShop tools and filters use 32-bit math.
> They're still working on it. Photoline has been a fully 32-bit
> math platform for the last 15 years.
>
mark, my computer math is pretty rusty but what does 16 bit
floating point or whatever vs. 32 bit or even 64 bit have anything
at all to do with color depth? Or, am I misunderstanding you? Is
what you're really saying that PS will cut down the color depth
back to 24 bit, do the function, then step it back up to 48 which
is pointless?
This is the first I've ever heard of Photoline, but then I'm hardly
a pro. But, 15 years ago? What motherboard or CPU was even remotely
capable of floating point math at 32 bits/channel? Or, am I again
misunderstanding you?
HEMI-Powered
...
> In article <tqo0i4pmkilcafeuo...@4ax.com>,
I'd believe that IF one has a 62 bit O/S
nospam
<no...@none.sn> wrote:
> mark, my computer math is pretty rusty but what does 16 bit
> floating point or whatever vs. 32 bit or even 64 bit have anything
> at all to do with color depth?
it doesn't. photoshop uses 32 bit math internally (or 64 bit in cs4)
when making calculations on an 8 bit per channel image.
HEMI-Powered
...
>> mark, my computer math is pretty rusty but what does 16 bit
>> floating point or whatever vs. 32 bit or even 64 bit have
>> anything at all to do with color depth?
>
> it doesn't. photoshop uses 32 bit math internally (or 64 bit
> in cs4) when making calculations on an 8 bit per channel
> image.
>
so, what does the bit width of the math to do with color depth at
all? if I understand your answer, nothing. so, while I have no skin
in this game, I'm curious as to the computer architecture side of
the issue regardless of whether 48 bit color does or doesn't make
sense in this instance.
thanks.
nospam
<no...@none.sn> wrote:
> >> mark, my computer math is pretty rusty but what does 16 bit
> >> floating point or whatever vs. 32 bit or even 64 bit have
> >> anything at all to do with color depth?
> >
> > it doesn't. photoshop uses 32 bit math internally (or 64 bit
> > in cs4) when making calculations on an 8 bit per channel
> > image.
>
> so, what does the bit width of the math to do with color depth at
> all? if I understand your answer, nothing.
basically, speed.
Floyd L. Davidson
>Hi all,
>
>I need to scan some old films using a 48 bits color depth (in order to keep
>the quality after some graphical process).
>My Canon CS5200F does it well but none of my graphical softwares can handle
>48 bits picture.
>
>The GIMP 2.6.2 translated my pictures from 48 to 24 bits.
Which may or may not actually make any difference to
you! The 8 bit internal format used by GIMP is gamma
corrected (intended to cause equal value changes to
result in approximately equal brightness changes in a
viewed image). Unless you are going to make large
changes using curves or levels, which will compress data
in some parts of the range and expand data in others, it
won't be important. For example, if you want the
scanned image to look *exactly* like the original film
image, it won't be a problem. If you want to do major
color correction or large gamma adjustments, then it
will.
Still, for minor adjustments that isn't a problem, but for
major changes it is.
I typically use /Cinepaint/, a free program with a user
interface that is almost identical to GIMP, for those
cases where 16-bit color depth is required.
>IrfanView does the same as the GIMP (48 => 24).
>I also tried XnView which is supposed to handle 48 bits pictures but when
>the picture is transfered from the scanner, I get a black screen (I tried
>in 24 bits and got the correct picture so this is really a color depth
>problem).
>
>I heard that the GIMP 2.6.2 was using a module called GECL which handles 48
>bits pictures but I did not find any to configure/activate it : my pictures
>are always handled as 24 bits picture.
At this point you have to use the Colors->Use_GEGL menu
item to enable the use of GEGL. However, while GEGL can
handle 16-bit depth images, the rest of GIMP, including
the internal image format, is still restricted to using
8-bit depth images. I do not know what the status of
that work is at this time. The 2.7 development thread
to date has shown nothing yet going in that direction,
so while it might happen before 2.8 is released it isn't
yet obvious.
>I do not want to buy any graphical software because many free ones exist.
>
>=> Do you know any free software or plugin which could work with 48 bits
>pictures acquired from a scanner ?
Get /cinepaint/.
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
Ray Fischer
> NeilMolon
>> I guess that's why everyone is raving about CS4 finally supporting some 32-bit
>> math in some of its functions.
>
>actually they're raving about cs4 being *64 bit*.
Too many people with too little understanding.
32-bit pixels is different from being able to handle a 64-bit address
space. Whining that PS cn't do 32-bit pixels for all functions is
silly given that there's no output device that can handle even a
16-bit range.
--
Ray Fischer
rfis...@sonic.net
nospam
<rfis...@sonic.net> wrote:
> 32-bit pixels is different from being able to handle a 64-bit address
> space.
right.
> Whining that PS cn't do 32-bit pixels for all functions is
> silly given that there's no output device that can handle even a
> 16-bit range.
16 bit printing is supported on cs4/mac.
Eric Stevens
<guilbert...@yahnomailoo.fr> wrote:
It's not free but Photo Paint will handle 48 bit RGB.
Eric Stevens
HEMI-Powered
...
>> >> mark, my computer math is pretty rusty but what does 16
>> >> bit floating point or whatever vs. 32 bit or even 64 bit
>> >> have anything at all to do with color depth?
>> >
>> > it doesn't. photoshop uses 32 bit math internally (or 64
>> > bit in cs4) when making calculations on an 8 bit per
>> > channel image.
>>
>> so, what does the bit width of the math to do with color
>> depth at all? if I understand your answer, nothing.
>
> basically, speed.
>
I DO understand that, IF the entire HW/SW system can support a
wider floating point math data I/O path. Still, that has no-thing
to do with 24 vs 48 bit color depth.
mark raif
>mark raif added these comments in the current discussion du jour
>...
>
>[snip]
>> If you save your scans in CMYK format then it will even
>> properly handle 64-bit color-depths. It's the only software
>> that I know of that can do this. PhotoShop still only uses
>> 16-bit math for most of its tools and functions. Wholly
>> incapable of retaining all that extra data during any
>> processing of these larger bit-depths. This has been a thorn
>> in the side of the "pro" world for the last 2 decades of using
>> PhotoShop, but they all seem to ignore it and live with it.
>> Only recently has Adobe started to add in some 32-bit math
>> routines to only some of their tools and features, but by no
>> means do all PhotoShop tools and filters use 32-bit math.
>> They're still working on it. Photoline has been a fully 32-bit
>> math platform for the last 15 years.
>>
>mark, my computer math is pretty rusty but what does 16 bit
>floating point or whatever vs. 32 bit or even 64 bit have anything
>at all to do with color depth? Or, am I misunderstanding you? Is
>what you're really saying that PS will cut down the color depth
>back to 24 bit, do the function, then step it back up to 48 which
>is pointless?
While all operating systems can load and view 32 and 64 bit color-depths
(usually by averaging to lower bit-depths if your display and software can't
handle it), that is where it ends. The moment you use an editor with only 16-bit
math you are starting to truncate valuable data during each process due to
rounding errors. Most will never notice it due to the limitations of their
display, but this loss does exist. This is why they put up with it in PhotoShop
for so long, what you can't see won't hurt you. For those that paid dearly to
get every bit-depth in their images they would like to have all that information
retained.
Let's say for example that you only have a 4-bit depth math package. 4-bit
floating-point math means that only FOUR significant binary characters can be
used to do the math. Any operation done on any color values will be truncated by
averaging mathematically. A decimal (not binary) example: If you have an RGB
pixel's red value of 38756 on a 16-bit color depth (values of 0 to 65535), and
you want to reduce that by 33%, you end up with a value of 12789.48. In a 4-bit
math platform that is rounded to 12790.00 Only 4-significant digits may be used,
the 89.48 is rounded to a value of 90. (Keeping in mind that in a 4-bit math
depth which is all performed in binary, using values 0-7, so the significant
digits in decimal (values 0-9) as presented here for examples, becomes much less
than this, even greater rounding is done sooner. This is only provided as a
quick example of what happens.) As more editing operations are performed those
approximated color values will carry over their errors and be duplicated. Each
time an operation is performed on that data then more math errors will be
introduced, always being rounded-off (lost) in the math functions. This is why
it's a good rule-of-thumb to always use at least the same or higher
floating-point math depth as your image color-depth. Perform 2 or more
operations on any set of pixels with a lower bit-depth math platform and you may
have drastically changed your color values by the time you are done. This is
precisely why PhotoShop could never incorporate the more advanced Lanczos-8
resampling algorithms. Its math platform was/is just incapable of doing the
calculations necessary to retain the image details during rotations and
resizings. The best that PhotoShop could ever offer was (and is) simplistic
bicubic interpolations, always resulting in muddy images and soft edges due to
lost details every time those operations are performed.
>
>This is the first I've ever heard of Photoline, but then I'm hardly
>a pro. But, 15 years ago? What motherboard or CPU was even remotely
>capable of floating point math at 32 bits/channel? Or, am I again
>misunderstanding you?
32-bit math has been around since Windows 3.1 if you installed the System32 math
package, and more commonly found in the very first versions of Windows 95, the
very first version of Win95 happening in 1993 (if you were one of the alpha
testers for MS, as I was). Windows 3.1 was primarily 16-bit math but allowed you
to use 32-bit software if your CPU allowed for it and if you installed some
accessory files (the origin of the "system32" Windows folder, there used to be
just a "system" folder in Win3.1). Photoline, originally called Photoline32,
recently renamed to just Photoline, was named that just because it was the ONLY
graphic editor that fully supported the new 32-bit math platform that started
during the Windows 3.1 to Window 95 bridge years.
A slight error, checking online I see now that Photoline32 was released in 1995.
I only know I was using it on the very first versions of Windows 95 when Win95
was released to the public (as the Windows-95 beta version due to a marketing
lawsuit that Gates didn't want to deal with, in-house memos that I was privy
to). The 2 year discrepancy about Photoline due to my alpha-testing phase of
Windows 95 which started in 1993. I only recall that I latched onto Photoline as
soon as I discovered its existence. It's been the backbone of my graphic editing
platform all these years due to how much more it can do and how much more
accurately it can do it. If someone hands me a complimentary copy of Photoshop,
I merely thank them, then after they have left I throw it in the waste-basket,
where it's always belonged. I wouldn't dare even give it to a friend, I wouldn't
want them to have to put up with that Adobe nonsense.
nospam
<mark...@privatedomain.net> wrote:
> 32-bit math has been around since Windows 3.1
32 bit math was available *long* before that.
> If someone hands me a complimentary copy of
> Photoshop,
> I merely thank them, then after they have left I throw it in the waste-basket,
> where it's always belonged. I wouldn't dare even give it to a friend, I wouldn't
> want them to have to put up with that Adobe nonsense.
so ebay it to a stranger.
mark raifr
>In article <oo01i4lvac2p30o1c...@4ax.com>, mark raif
><mark...@privatedomain.net> wrote:
>
>> 32-bit math has been around since Windows 3.1
>
>32 bit math was available *long* before that.
I believe we are discussing desktop computers and home ran operating systems.
Not early mainframes that have nothing to do with the topic. "The topic" which
you so quickly try to avoid at every turn. Trolls are like that. That's all they
can bring to a discussion, to get that attention that they so desperately crave,
from anyone or anything possible.
>
>> If someone hands me a complimentary copy of
>> Photoshop,
>> I merely thank them, then after they have left I throw it in the waste-basket,
>> where it's always belonged. I wouldn't dare even give it to a friend, I wouldn't
>> want them to have to put up with that Adobe nonsense.
>
>so ebay it to a stranger.
I have more respect than that for someone I don't know. But to you? I'd sell it
to you in a heartbeat for $1 less than the going rate.
nospam
<mark...@privatedomain.net> wrote:
> >> 32-bit math has been around since Windows 3.1
> >
> >32 bit math was available *long* before that.
>
> I believe we are discussing desktop computers and home ran operating systems.
mainframes certainly did, but if you want to restrict it to desktop
computers, that's fine too. the macintosh was a 32 bit machine since
its introduction in january 1984 and photoshop debuted on the mac in
1990, appearing on windows a couple of years later with 32 bit math
internally on both platforms.
and cpu bus width isn't the determining factor either. even on an 8
bit computer, one can do higher precision math, it just takes more
instructions.
Jürgen Exner
>On Sun, 16 Nov 2008 16:55:35 -0500, nospam <nos...@nospam.invalid> wrote:
>
>>In article <oo01i4lvac2p30o1c...@4ax.com>, mark raif
>><mark...@privatedomain.net> wrote:
>>
>>> 32-bit math has been around since Windows 3.1
>>
>>32 bit math was available *long* before that.
>
>I believe we are discussing desktop computers and home ran operating systems.
>Not early mainframes that have nothing to do with the topic.
I wasn't aware that the 80386 (introduced 1985, produced in significant
numbers from 1986) )was used in mainframes instead of in desktop
computer.
Windows 3.1 came in 1992, which at least to me is 6 years _AFTER_ the
introduction of 32-bit math.
jue
JoseJ
>In article <5t61i4t7antphkecb...@4ax.com>, mark raifr
><mark...@privatedomain.net> wrote:
>
>> >> 32-bit math has been around since Windows 3.1
>> >
>> >32 bit math was available *long* before that.
>>
>> I believe we are discussing desktop computers and home ran operating systems.
>
>mainframes certainly did, but if you want to restrict it to desktop
>computers, that's fine too. the macintosh was a 32 bit machine since
>its introduction in january 1984 and photoshop debuted on the mac in
>1990, appearing on windows a couple of years later with 32 bit math
>internally on both platforms.
Too bad that never applied to the majority of Photoshop users that are on PCs.
They've had to deal with a 16-bit math package in Photoshop all these years, but
never realizing it.
btw: The operating system does not define the math bit-depth of the software.
You could very well have been running the same 16-bit Photoshop on your Mac all
those years without even realizing it. Mac users never have been too bright,
they want some corporation to wipe their ass for them and pay out the ass for
having them do so.
HEMI-Powered
...
> While all operating systems can load and view 32 and 64 bit
32 bits of binary floating point are only good for about 8 or
maybe nine significant digits hence prior to the 60-bit CDC
mainframes contracted by DoD back in the 1960s and 1970s, IBM
mainframes, mini-computers and such needed double precision to
get to 11-12 digits after the decimal point. But, there was never
any rounding, it was really simply binary truncation, a far worse
problem.
There are also issues involving whether the floating point is in
hardware or software wrt rounding or truncating.
None of this had diddly to do with color depth unless you are
saying that any advantage is destroyed by a processor, data bus,
O/S or something else throw away what color there is.
But, on an ordinary PC even with a 32 bit O/S, 64 bit arithmetic
can still be simulated IF the data is grabbed in two chunks,
processed, then stored back. However, that would be deathly slow.
>>
>>This is the first I've ever heard of Photoline, but then I'm
>>hardly a pro. But, 15 years ago? What motherboard or CPU was
>>even remotely capable of floating point math at 32
>>bits/channel? Or, am I again misunderstanding you?
>
> 32-bit math has been around since Windows 3.1 if you installed
> the System32 math package, and more commonly found in the very
> first versions of Windows 95, the very first version of Win95
> happening in 1993 (if you were one of the alpha testers for
> MS, as I was). Windows 3.1 was primarily 16-bit math but
> allowed you to use 32-bit software if your CPU allowed for it
> and if you installed some accessory files (the origin of the
> "system32" Windows folder, there used to be just a "system"
> folder in Win3.1). Photoline, originally called Photoline32,
> recently renamed to just Photoline, was named that just
> because it was the ONLY graphic editor that fully supported
> the new 32-bit math platform that started during the Windows
> 3.1 to Window 95 bridge years.
Can't really speak to that as I was neither a system programmer
nor an application one for Win 3.1 or any other version. But,
what good would any of this be in the first place with the
motherboards and memory of that era? Win 3.1 could barely stay up
for more than an hour without crashing, so I'm sorry, but I can't
see how this might work. I clearly do not know, I just wonder,
that's all.
> A slight error, checking online I see now that Photoline32 was
> released in 1995. I only know I was using it on the very first
> versions of Windows 95 when Win95 was released to the public
> (as the Windows-95 beta version due to a marketing lawsuit
> that Gates didn't want to deal with, in-house memos that I was
> privy to). The 2 year discrepancy about Photoline due to my
> alpha-testing phase of Windows 95 which started in 1993. I
> only recall that I latched onto Photoline as soon as I
> discovered its existence. It's been the backbone of my graphic
> editing platform all these years due to how much more it can
> do and how much more accurately it can do it. If someone hands
> me a complimentary copy of Photoshop, I merely thank them,
> then after they have left I throw it in the waste-basket,
> where it's always belonged. I wouldn't dare even give it to a
> friend, I wouldn't want them to have to put up with that Adobe
> nonsense.
>
If I am following this at all, I'm still confused - for purely
curiosity reasons - why anyone would want to use 32 bit math in a
64-bit world (now).
This has been an excellent theoretical discussion and I thank you
for taking the time to write all of this. Now, could you please
return to Earth and explain how I might be affected or the OP,
who simply wants - for some reason - to do some free 48 bit work.
I stopped doing anything in FORTRAN more than 20 years ago, and
about the time that Photoline was released, I'd come to a mind-
boggling conclusion: that my PC was to do useful work for me, not
be a hobbyist play toy.
I assume you have some professional need for all of this
technocracy or maybe you just love pushing a PC to it's limits. I
am envious of your ability, so again, I thank you and I think
I'll go back to watching TV. <grin>
HEMI-Powered
...
> In article <oo01i4lvac2p30o1c...@4ax.com>, mark
> raif <mark...@privatedomain.net> wrote:
>
>> 32-bit math has been around since Windows 3.1
>
> 32 bit math was available *long* before that.
In the world of computer science or PCs? I programmed on a 60-bit
word CDC mainframe for a number of years from the late 1970s to
1985 when I went over to the Dark Side and became a
supervisor.Those things were fantastic with at least 11 decimal
digits of precision after the decimal point. CDC originally was
formed to build computers for DoD that could do floating point far
more quickly than the IBMs of the day that needed double-precision
in SW that was inherently very slow.
>> If someone hands me a complimentary copy of
>> Photoshop,
>> I merely thank them, then after they have left I throw it in
>> the waste-basket, where it's always belonged. I wouldn't dare
>> even give it to a friend, I wouldn't want them to have to put
>> up with that Adobe nonsense.
>
> so ebay it to a stranger.
>
HEMI-Powered
jour ...
>>> 32-bit math has been around since Windows 3.1
>>
>>32 bit math was available *long* before that.
>
> I believe we are discussing desktop computers and home ran
> operating systems. Not early mainframes that have nothing to
> do with the topic. "The topic" which you so quickly try to
> avoid at every turn. Trolls are like that. That's all they can
> bring to a discussion, to get that attention that they so
> desperately crave, from anyone or anything possible.
this is precisely the confusion I have, mark. even after reading
your excellent treatise, I admit to being very confused, but in my
case, it really isn't necessary that I be conversant here.
Paul Furman
> HEMI-Powered wrote:
>
>> mark,
He's not 'mark', he's the P&S troll posting so many crazy rants in here
recently with dozens of different names. Don't take him seriously.
HEMI-Powered
...
>> >> 32-bit math has been around since Windows 3.1
>> >
>> >32 bit math was available *long* before that.
>>
>> I believe we are discussing desktop computers and home ran
>> operating systems.
>
> mainframes certainly did, but if you want to restrict it to
> desktop computers, that's fine too. the macintosh was a 32
> bit machine since its introduction in january 1984 and
> photoshop debuted on the mac in 1990, appearing on windows a
> couple of years later with 32 bit math internally on both
> platforms.
>
> and cpu bus width isn't the determining factor either. even
> on an 8 bit computer, one can do higher precision math, it
> just takes more instructions.
>
one more time, please, isn't what is really necessary is 64-bit
math? and, yes, you are obviously correct that any bit-length math
can be done IF one is willing to spend enough instructions and
enough CPU cycles to fetch the data, compute a result of some
algorithm, then write it back out across the short bus. my point in
an earlier reply was that this is a fairly academic debate since
this isn't either 1984 or 1995, we now have vastly superior HW
architectures, but we are also plagued with O/S and app bloatware
so severe that even Moore's Law is overwhelmed.
At one time, talented programmers hand optimizing assembly code
could wring fantastic performance out of even 8bit CPUs yet now, we
have reached the point where heat buildup prevents any increase in
clock speeds now requiring parallel processing. And, so the saga
continues.
Ray Fischer
nelson-ganes
>nospam wrote:
>> HEMI-Powered wrote:
>>
>>> mark,
>
>He's not 'mark', he's the P&S troll posting so many crazy rants in here
>recently with dozens of different names. Don't take him seriously.
>
>
Dear Resident-Troll,
Your post is completely off-topic. Here are some topics that befit this
newsgroup. Please consider them for future discussions and posts:
1. P&S cameras can have more seamless zoom range than any DSLR glass in
existence. (E.g. 9mm f2.7 - 1248mm f/3.5.) There are now some excellent
wide-angle and telephoto (tel-extender) add-on lenses for many makes and models
of P&S cameras. Add either or both of these small additions to your photography
gear and, with some of the new super-zoom P&S cameras, you can far surpass any
range of focal-lengths and apertures that are available or will ever be made for
larger format cameras.
2. P&S cameras can have much wider apertures at longer focal lengths than any
DSLR glass in existence. (E.g. 549mm f/2.4 and 1248mm f/3.5) when used with
high-quality tel-extenders, which by the way, do not reduce the lens' original
aperture one bit. Only DSLRs suffer from that problem due to the manner in which
their tele-converters work. They can also have higher quality full-frame
180-degree circular fisheye and intermediate super-wide-angle views than any
DSLR and its glass in existence. Some excellent fish-eye adapters can be added
to your P&S camera which do not impart any chromatic-aberration nor
edge-softness. When used with a super-zoom P&S camera this allows you to
seamlessly go from as wide as a 9mm (or even wider) 35mm equivalent focal-length
up to the wide-angle setting of the camera's own lens.
3. P&S smaller sensor cameras can and do have wider dynamic range than larger
sensor cameras E.g. a 1/2.5" sized sensor can have a 10.3EV Dynamic Range vs. an
APS-C's typical 7.0-8.0EV Dynamic Range. One quick example:
http://farm4.static.flickr.com/3142/2861257547_9a7ceaf3a1_o.jpg
4. P&S cameras are cost efficient. Due to the smaller (but excellent) sensors
used in many of them today, the lenses for these cameras are much smaller.
Smaller lenses are easier to manufacture to exacting curvatures and are more
easily corrected for aberrations than larger glass used for DSLRs. This also
allows them to perform better at all apertures rather than DSLR glass which is
only good for one aperture setting per lens. Side by side tests prove that P&S
glass can out-resolve even the best DSLR glass ever made. After all is said and
done, you will spend 1/4th to 1/50th the price that you would have to in order
to get comparable performance in a DSLR camera. When you buy a DSLR you are
investing in a body that will require expensive lenses, hand-grips, external
flash units, heavy tripods, more expensive larger filters, etc. etc. The
outrageous costs of owning a DSLR add up fast after that initial DSLR body
purchase. Camera companies count on this, all the way to their banks.
5. P&S cameras are lightweight and convenient. With just one P&S camera plus one
small wide-angle adapter and one small telephoto adapter weighing just a couple
pounds, you have the same amount of zoom range as would require over 10 to 20
pounds of DSLR body and lenses. You can carry the whole P&S kit in one roomy
pocket of a wind-breaker or jacket. The DSLR kit would require a sturdy
backpack. You also don't require a massive tripod. Large tripods are required to
stabilize the heavy and unbalanced mass of the larger DSLR and its massive
lenses. A P&S camera, being so light, can be used on some of the most
inexpensive, compact, and lightweight tripods with excellent results.
6. P&S cameras are silent. For the more common snap-shooter/photographer, you
will not be barred from using your camera at public events, stage-performances,
and ceremonies. Or when trying to capture candid shots, you won't so easily
alert all those within a block around, from the obnoxious noise that your DSLR
is making, that you are capturing anyone's images. For the more dedicated
wildlife photographer a P&S camera will not endanger your life when
photographing potentially dangerous animals by alerting them to your presence.
7. Some P&S cameras can run the revolutionary CHDK software on them, which
allows for lightning-fast motion detection (literally, lightning fast 45ms
response time, able to capture lightning strikes automatically) so that you may
capture more elusive and shy animals (in still-frame and video) where any
evidence of your presence at all might prevent their appearance. Without the
need of carrying a tethered laptop along or any other hardware into remote
areas--which only limits your range, distance, and time allotted for bringing
back that one-of-a-kind image. It also allows for unattended time-lapse
photography for days and weeks at a time, so that you may capture those unusual
or intriguing subject-studies in nature. E.g. a rare slime-mold's propagation,
that you happened to find in a mountain-ravine, 10-days hike from the nearest
laptop or other time-lapse hardware. (The wealth of astounding new features that
CHDK brings to the creative-table of photography are too extensive to begin to
list them all here. See http://chdk.wikia.com/wiki/CHDK )
8. P&S cameras can have shutter speeds up to 1/40,000th of a second. See:
http://chdk.wikia.com/wiki/CameraFeatures Allowing you to capture fast subject
motion in nature (e.g. insect and hummingbird wings) WITHOUT the need of
artificial and image destroying flash, using available light alone. Nor will
their wing shapes be unnaturally distorted from the focal-plane shutter
distortions imparted in any fast moving objects, as when photographed with all
DSLRs. (See focal-plane-shutter-distortions example-image link in #10.)
9. P&S cameras can have full-frame flash-sync up to and including shutter-speeds
of 1/40,000th of a second. E.g.
http://chdk.wikia.com/wiki/Samples:_High-Speed_Shutter_%26_Flash-Sync without
the use of any expensive and specialized focal-plane shutter flash-units that
must strobe for the full duration of the shutter's curtain to pass over the
frame. The other downside to those kinds of flash units, is that the
light-output is greatly reduced the faster the shutter speed. Any shutter speed
used that is faster than your camera's X-Sync speed is cutting off some of the
flash output. Not so when using a leaf-shutter. The full intensity of the flash
is recorded no matter the shutter speed used. Unless, as in the case of CHDK
capable cameras where the camera's shutter speed can even be faster than the
lightning-fast single burst from a flash unit. E.g. If the flash's duration is
1/10,000 of a second, and your CHDK camera's shutter is set to 1/20,000 of a
second, then it will only record half of that flash output. P&S cameras also
don't require any expensive and dedicated external flash unit. Any of them may
be used with any flash unit made by using an inexpensive slave-trigger that can
compensate for any automated pre-flash conditions. Example:
http://www.adorama.com/SZ23504.html
10. P&S cameras do not suffer from focal-plane shutter drawbacks and
limitations. Causing camera shake, moving-subject image distortions
(focal-plane-shutter distortions, e.g.
http://images3.wikia.nocookie.net/chdk/images//4/46/Focalplane_shutter_distortions.jpg
do note the distorted tail-rotor too and its shadow on the ground, 90-degrees
from one another), last-century-slow flash-sync, obnoxiously loud slapping
mirrors and shutter curtains, shorter mechanical life, easily damaged, expensive
repair costs, etc.
11. When doing wildlife photography in remote and rugged areas and harsh
environments, or even when the amateur snap-shooter is trying to take their
vacation photos on a beach or dusty intersection on some city street, you're not
worrying about trying to change lenses in time to get that shot (fewer missed
shots), dropping one in the mud, lake, surf, or on concrete while you do, and
not worrying about ruining all the rest of your photos that day from having
gotten dust & crud on the sensor. For the adventurous photographer you're no
longer weighed down by many many extra pounds of unneeded glass, allowing you to
carry more of the important supplies, like food and water, allowing you to trek
much further than you've ever been able to travel before with your old D/SLR
bricks.
12. Smaller sensors and the larger apertures available allow for the deep DOF
required for excellent macro-photography, WITHOUT the need of any image
destroying, subject irritating, natural-look destroying flash. No DSLR on the
planet can compare in the quality of available-light macro photography that can
be accomplished with nearly any smaller-sensor P&S camera.
13. P&S cameras include video, and some even provide for CD-quality stereo audio
recordings, so that you might capture those rare events in nature where a
still-frame alone could never prove all those "scientists" wrong. E.g. recording
the paw-drumming communication patterns of eusocial-living field-mice. With your
P&S video-capable camera in your pocket you won't miss that once-in-a-lifetime
chance to record some unexpected event, like the passage of a bright meteor in
the sky in daytime, a mid-air explosion, or any other newsworthy event. Imagine
the gaping hole in our history of the Hindenberg if there were no film cameras
there at the time. The mystery of how it exploded would have never been solved.
Or the amateur 8mm film of the shooting of President Kennedy. Your video-ready
P&S camera being with you all the time might capture something that will be a
valuable part of human history one day.
14. P&S cameras have 100% viewfinder coverage that exactly matches your final
image. No important bits lost, and no chance of ruining your composition by
trying to "guess" what will show up in the final image. With the ability to
overlay live RGB-histograms, and under/over-exposure area alerts (and dozens of
other important shooting data) directly on your electronic viewfinder display
you are also not going to guess if your exposure might be right this time. Nor
do you have to remove your eye from the view of your subject to check some
external LCD histogram display, ruining your chances of getting that perfect
shot when it happens.
15. P&S cameras can and do focus in lower-light (which is common in natural
settings) than any DSLRs in existence, due to electronic viewfinders and sensors
that can be increased in gain for framing and focusing purposes as light-levels
drop. Some P&S cameras can even take images (AND videos) in total darkness by
using IR illumination alone. (See: Sony) No other multi-purpose cameras are
capable of taking still-frame and videos of nocturnal wildlife as easily nor as
well. Shooting videos and still-frames of nocturnal animals in the total-dark,
without disturbing their natural behavior by the use of flash, from 90 ft. away
with a 549mm f/2.4 lens is not only possible, it's been done, many times, by
myself. (An interesting and true story: one wildlife photographer was nearly
stomped to death by an irate moose that attacked where it saw his camera's flash
come from.)
16. Without the need to use flash in all situations, and a P&S's nearly 100%
silent operation, you are not disturbing your wildlife, neither scaring it away
nor changing their natural behavior with your existence. Nor, as previously
mentioned, drawing its defensive behavior in your direction. You are recording
nature as it is, and should be, not some artificial human-changed distortion of
reality and nature.
17. Nature photography requires that the image be captured with the greatest
degree of accuracy possible. NO focal-plane shutter in existence, with its
inherent focal-plane-shutter distortions imparted on any moving subject will
EVER capture any moving subject in nature 100% accurately. A leaf-shutter or
electronic shutter, as is found in ALL P&S cameras, will capture your moving
subject in nature with 100% accuracy. Your P&S photography will no longer lead a
biologist nor other scientist down another DSLR-distorted path of non-reality.
18. Some P&S cameras have shutter-lag times that are even shorter than all the
popular DSLRs, due to the fact that they don't have to move those agonizingly
slow and loud mirrors and shutter curtains in time before the shot is recorded.
In the hands of an experienced photographer that will always rely on prefocusing
their camera, there is no hit & miss auto-focusing that happens on all
auto-focus systems, DSLRs included. This allows you to take advantage of the
faster shutter response times of P&S cameras. Any pro worth his salt knows that
if you really want to get every shot, you don't depend on automatic anything in
any camera.
19. An electronic viewfinder, as exists in all P&S cameras, can accurately relay
the camera's shutter-speed in real-time. Giving you a 100% accurate preview of
what your final subject is going to look like when shot at 3 seconds or
1/20,000th of a second. Your soft waterfall effects, or the crisp sharp outlines
of your stopped-motion hummingbird wings will be 100% accurately depicted in
your viewfinder before you even record the shot. What you see in a P&S camera is
truly what you get. You won't have to guess in advance at what shutter speed to
use to obtain those artistic effects or those scientifically accurate nature
studies that you require or that your client requires. When testing CHDK P&S
cameras that could have shutter speeds as fast as 1/40,000th of a second, I was
amazed that I could half-depress the shutter and watch in the viewfinder as a
Dremel-Drill's 30,000 rpm rotating disk was stopped in crisp detail in real
time, without ever having taken an example shot yet. Similarly true when
lowering shutter speeds for milky-water effects when shooting rapids and falls,
instantly seeing the effect in your viewfinder. Poor DSLR-trolls will never
realize what they are missing with their anciently slow focal-plane shutters and
wholly inaccurate optical viewfinders.
20. P&S cameras can obtain the very same bokeh (out of focus foreground and
background) as any DSLR by just increasing your focal length, through use of its
own built-in super-zoom lens or attaching a high-quality telextender on the
front. Just back up from your subject more than you usually would with a DSLR.
Framing and the included background is relative to the subject at the time and
has nothing at all to do with the kind of camera and lens in use. Your f/ratio
(which determines your depth-of-field), is a computation of focal-length divided
by aperture diameter. Increase the focal-length and you make your DOF shallower.
No different than opening up the aperture to accomplish the same. The two
methods are identically related where DOF is concerned.
21. P&S cameras will have perfectly fine noise-free images at lower ISOs with
just as much resolution as any DSLR camera. Experienced Pros grew up on ISO25
and ISO64 film all their lives. They won't even care if their P&S camera can't
go above ISO400 without noise. An added bonus is that the P&S camera can have
larger apertures at longer focal-lengths than any DSLR in existence. The time
when you really need a fast lens to prevent camera-shake that gets amplified at
those focal-lengths. Even at low ISOs you can take perfectly fine hand-held
images at super-zoom settings. Whereas the DSLR, with its very small apertures
at long focal lengths require ISOs above 3200 to obtain the same results. They
need high ISOs, you don't. If you really require low-noise high ISOs, there are
some excellent models of Fuji P&S cameras that do have noise-free images up to
ISO1600 and more.
22. Don't for one minute think that the price of your camera will in any way
determine the quality of your photography. Any of the newer cameras of around
$100 or more are plenty good for nearly any talented photographer today. IF they
have talent to begin with. A REAL pro can take an award winning photograph with
a cardboard Brownie Box camera made a century ago. If you can't take excellent
photos on a P&S camera then you won't be able to get good photos on a DSLR
either. Never blame your inability to obtain a good photograph on the kind of
camera that you own. Those who claim they NEED a DSLR are only fooling
themselves and all others. These are the same people that buy a new camera every
year, each time thinking, "Oh, if I only had the right camera, a better camera,
better lenses, faster lenses, then I will be a great photographer!" Camera
company's love these people. They'll never be able to get a camera that will
make their photography better, because they never were a good photographer to
begin with. The irony is that by them thinking that they only need to throw
money at the problem, they'll never look in the mirror to see what the real
problem is. They'll NEVER become good photographers. Perhaps this is why these
self-proclaimed "pros" hate P&S cameras so much. P&S cameras instantly reveal to
them their piss-poor photography skills.
23. Have you ever had the fun of showing some of your exceptional P&S
photography to some self-proclaimed "Pro" who uses $30,000 worth of camera gear.
They are so impressed that they must know how you did it. You smile and tell
them, "Oh, I just use a $150 P&S camera." Don't you just love the look on their
face? A half-life of self-doubt, the realization of all that lost money, and a
sadness just courses through every fiber of their being. Wondering why they
can't get photographs as good after they spent all that time and money. Get good
on your P&S camera and you too can enjoy this fun experience.
24. Did we mention portability yet? I think we did, but it is worth mentioning
the importance of this a few times. A camera in your pocket that is instantly
ready to get any shot during any part of the day will get more award-winning
photographs than that DSLR gear that's sitting back at home, collecting dust,
and waiting to be loaded up into that expensive back-pack or camera bag, hoping
that you'll lug it around again some day.
25. A good P&S camera is a good theft deterrent. When traveling you are not
advertising to the world that you are carrying $20,000 around with you. That's
like having a sign on your back saying, "PLEASE MUG ME! I'M THIS STUPID AND I
DESERVE IT!" Keep a small P&S camera in your pocket and only take it out when
needed. You'll have a better chance of returning home with all your photos. And
should you accidentally lose your P&S camera you're not out $20,000. They are
inexpensive to replace.
There are many more reasons to add to this list but this should be more than
enough for even the most unaware person to realize that P&S cameras are just
better, all around. No doubt about it.
The phenomenon of everyone yelling "You NEED a DSLR!" can be summed up in just
one short phrase:
"If even 5 billion people are saying and doing a foolish thing, it remains a
foolish thing."
peter_k_bryansen
>my point in
>an earlier reply was that this is a fairly academic debate since
>this isn't either 1984 or 1995, we now have vastly superior HW
>architectures, but we are also plagued with O/S and app bloatware
>so severe that even Moore's Law is overwhelmed.
And that is the point being made. Trying to use software which only has 16-bit
math as the majority of it's functions (i.e. Photoshop) on 48-bit or 64-bit
color-depth data, is like going back to 1984.
HEMI-Powered
jour ...
>>> mark,
>
> He's not 'mark', he's the P&S troll posting so many crazy
> rants in here recently with dozens of different names. Don't
> take him seriously.
I'm not a big fan of abuse reporting wars, Paul, but if we have a
nym shifter or a sporger amongst us, wouldn't getting his ass
removed be better? I understand your point and I thank you, but
absent a LOT of time looking at headers, how does one figure out
who is real and who is Memorex here?
Thanks.
HEMI-Powered
jour ...
> On Sun, 16 Nov 2008 15:00:12 -0800, Paul Furman
> shutter_distortions.jpg do note the distorted tail-rotor too
I just love two guys measuring their dicks in the shower room!
Isn't just the tiniest possibility that someone might actually
want BOTH a small P& S and a quality DSLR? Dang, got that!
Ray Fischer
Except that PS has 8, 16, or 32-bit math PER CHANNEL on its images.
Understand the difference? Three channels times 16 bits per channel
is 48 bits. Of course, these programs support many more than just
three channels, which is why you seldom see "48-bit color".
--
Ray Fischer
rfis...@sonic.net
John McWilliams
I print to an Epson 3800 in 16 bit mode out of Lightroom. But I also get
your point about whining.
Now if only the bitching would stop.
--
john mcwilliams
John McWilliams
>>
> I just love two guys measuring their dicks in the shower room!
> Isn't just the tiniest possibility that someone might actually
> want BOTH a small P& S and a quality DSLR? Dang, got that!
Yes, Jerry, but this has been going on for weeks. Could you and Paul
possibly just refrain from replying to the pest?
Yes, he will tack on his mission as a reply to this, but I won't answer
that. I reply only to those who are intelligent and can modify behavior!
Well, not exclusively, but you and Paul certainly fit.
--
john mcwilliams
Alan Browne
The point about data precision in PS is not about output. It is about
conserving information over a few to dozens of transforms (operations)
of the data without introducing artifacts due to LSB losses or padding
in each transform such that when the data is eventually reduced to the
dynamic range of the output, all (or at least most) processing artifacts
are lost in the truncated or rounded data only in that very last operation.
--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: Remove FreeLunch.
-- usenet posts from gmail.com and googlemail.com are filtered out.
nospam
<no...@none.sn> wrote:
> >> 32-bit math has been around since Windows 3.1
> >
> > 32 bit math was available *long* before that.
>
> In the world of computer science or PCs? I programmed on a 60-bit
> word CDC mainframe for a number of years from the late 1970s to
> 1985
that's actually the machine i was thinking of. was it a cyber 175? 60
bit words were fun.
nospam
<jo...@spamblocker.org> wrote:
> Too bad that never applied to the majority of Photoshop users that are on PCs.
> They've had to deal with a 16-bit math package in Photoshop all these years,
> but
> never realizing it.
no matter how often you say it, it's still wrong.
Floyd L. Davidson
>peter_k_bryansen <pkbry...@whomsoever.com> wrote:
>>On Sun, 16 Nov 2008 17:03:23 -0600, "HEMI-Powered" <no...@none.sn> wrote:
>>
>>>my point in
>>>an earlier reply was that this is a fairly academic debate since
>>>this isn't either 1984 or 1995, we now have vastly superior HW
>>>architectures, but we are also plagued with O/S and app bloatware
>>>so severe that even Moore's Law is overwhelmed.
>>
>>And that is the point being made. Trying to use software which only has 16-bit
>>math as the majority of it's functions (i.e. Photoshop) on 48-bit or 64-bit
>>color-depth data, is like going back to 1984.
>
>Except that PS has 8, 16, or 32-bit math PER CHANNEL on its images.
Nonsense. Math is not "per channel". Bit depth is per
channel. It is possible to use 16 bit math (or 64 bit
math) on 8 bit depth data or on 32 bit depth data.
The number of bits for math is a measure of math
precision when doing calculation. The number of bits
for color is a measure of the color precision when the
results of the calculation are saved.
Bit depth and math are distinctly *different*.
>Understand the difference? Three channels times 16 bits per channel
>is 48 bits. Of course, these programs support many more than just
>three channels, which is why you seldom see "48-bit color".
"48-bit color" refers to an RGB image format. I don't
know where you get the "many more than just three
channels", because the only common formats are either 3
color or 4 color, not "many more than just three.
Regardless, PS can work with images in 8, 16 or 32 bit
per channel *color*. That is not the math precision.
I do not know what math precision PS uses internally.
The claim that it uses 16 bit math for some calculation
is not irrational, though I do not know if it is true or
not. It is not uncommon to implement a platform
independant math package for a application. (CAD and
typesetting programs are two places where that would be
the norm.) The purpose is to insure precisely the same
results regardless of the hardware platform. Hence PS
might well implement its own math package for some
calculations, and *because* of that it would produce the
exact same results on virtually any platform that it is
ported to; which is not exactly a bad thing, eh?
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
nospam
<fl...@apaflo.com> wrote:
> Nonsense. Math is not "per channel". Bit depth is per
> channel. It is possible to use 16 bit math (or 64 bit
> math) on 8 bit depth data or on 32 bit depth data.
>
> The number of bits for math is a measure of math
> precision when doing calculation. The number of bits
> for color is a measure of the color precision when the
> results of the calculation are saved.
>
> Bit depth and math are distinctly *different*.
right.
> >Understand the difference? Three channels times 16 bits per channel
> >is 48 bits. Of course, these programs support many more than just
> >three channels, which is why you seldom see "48-bit color".
>
> "48-bit color" refers to an RGB image format. I don't
> know where you get the "many more than just three
> channels", because the only common formats are either 3
> color or 4 color, not "many more than just three.
photoshop is not limited to 4 channels, although the vast majority of
images will be 3 or 4 channels,
> Regardless, PS can work with images in 8, 16 or 32 bit
> per channel *color*. That is not the math precision.
yep.
> I do not know what math precision PS uses internally.
> The claim that it uses 16 bit math for some calculation
> is not irrational, though I do not know if it is true or
> not.
it's false.
> It is not uncommon to implement a platform
> independant math package for a application. (CAD and
> typesetting programs are two places where that would be
> the norm.) The purpose is to insure precisely the same
> results regardless of the hardware platform. Hence PS
> might well implement its own math package for some
> calculations, and *because* of that it would produce the
> exact same results on virtually any platform that it is
> ported to; which is not exactly a bad thing, eh?
that's exactly what it does.
Ray Fischer
>John McWilliams wrote:
>> Ray Fischer wrote:
>>> nospam <nos...@nospam.invalid> wrote:
>>>> NeilMolon
>>>
>>>>> I guess that's why everyone is raving about CS4 finally supporting
>>>>> some 32-bit
>>>>> math in some of its functions.
>>>> actually they're raving about cs4 being *64 bit*.
>>>
>>> Too many people with too little understanding.
>>>
>>> 32-bit pixels is different from being able to handle a 64-bit address
>>> space. Whining that PS cn't do 32-bit pixels for all functions is
>>> silly given that there's no output device that can handle even a
>>> 16-bit range.
>>
>> I print to an Epson 3800 in 16 bit mode out of Lightroom. But I also get
>> your point about whining.
>
>The point about data precision in PS is not about output. It is about
>conserving information over a few to dozens of transforms (operations)
>of the data without introducing artifacts due to LSB losses or padding
>in each transform such that when the data is eventually reduced to the
>dynamic range of the output, all (or at least most) processing artifacts
>are lost in the truncated or rounded data only in that very last operation.
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.
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
>>peter_k_bryansen <pkbry...@whomsoever.com> wrote:
>>>On Sun, 16 Nov 2008 17:03:23 -0600, "HEMI-Powered" <no...@none.sn> wrote:
>>>
>>>>my point in
>>>>an earlier reply was that this is a fairly academic debate since
>>>>this isn't either 1984 or 1995, we now have vastly superior HW
>>>>architectures, but we are also plagued with O/S and app bloatware
>>>>so severe that even Moore's Law is overwhelmed.
>>>
>>>And that is the point being made. Trying to use software which only has 16-bit
>>>math as the majority of it's functions (i.e. Photoshop) on 48-bit or 64-bit
>>>color-depth data, is like going back to 1984.
>>
>>Except that PS has 8, 16, or 32-bit math PER CHANNEL on its images.
>
>Nonsense. Math is not "per channel".
Of course it is. I've CS4 running right in front of me. One can
easily do operations on single channels or combine them.
> Bit depth is per
>channel. It is possible to use 16 bit math (or 64 bit
>math) on 8 bit depth data or on 32 bit depth data.
Photoshop allows for many channels. Not just the common R, G, &B.
>The number of bits for math is a measure of math
>precision when doing calculation.
No kidding?
> The number of bits
>for color is a measure of the color precision when the
>results of the calculation are saved.
>
>Bit depth and math are distinctly *different*.
Idiot.
>>Understand the difference? Three channels times 16 bits per channel
>>is 48 bits. Of course, these programs support many more than just
>>three channels, which is why you seldom see "48-bit color".
>
>"48-bit color" refers to an RGB image format.
Sometimes. What about 64-bit color? Would you know that that refers
to CMYK at 16-bits per channel? Or LAB color at 16-bits per channel?
> I don't
>know where you get the "many more than just three
>channels", because the only common formats are either 3
>color or 4 color, not "many more than just three.
You've never used Photoshop, have you?
>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.
>I do not know what math precision PS uses internally.
Ah, so you really don't know what you're blathering about.
>The claim that it uses 16 bit math for some calculation
Did you forget that you don't know what you're blathering about?
--
Ray Fischer
rfis...@sonic.net
Brandon B. Gaston
>I just love two guys measuring their dicks in the shower room!
It's been obviouis since your diatribes against gay-marriages of what you really
enjoy. It's nice to see your follow-up comments reaffirm what everyone's already
deduced about you being an insecure closet-case that's only trying to appear
macho online with the screen-name of "Hemi-Powered". Overcompensate much?
Doug McDonald
> On Sun, 16 Nov 2008 16:55:35 -0500, nospam <nos...@nospam.invalid> wrote:
>
>> In article <oo01i4lvac2p30o1c...@4ax.com>, mark raif
>> <mark...@privatedomain.net> wrote:
>>
>>> 32-bit math has been around since Windows 3.1
>> 32 bit math was available *long* before that.
>
> I believe we are discussing desktop computers and home ran operating systems.
The very first IBM PC had full 32 and 64 bit floating point IN HARDWARE.
Yes, you had to pay about $150 or so I remember for the extra chip,
but it was seamless integration, and it worked just fine. It was fully
supported.
Doug McDonald
Eric Stevens
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.
This is NOT the same as the number of bits used in the RGB/CMYK data
channels used to describe the images.
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.
Eric Stevens
Eric Stevens
He's correct.
>
>>>Understand the difference? Three channels times 16 bits per channel
>>>is 48 bits. Of course, these programs support many more than just
>>>three channels, which is why you seldom see "48-bit color".
>>
>>"48-bit color" refers to an RGB image format.
>
>Sometimes. What about 64-bit color? Would you know that that refers
>to CMYK at 16-bits per channel? Or LAB color at 16-bits per channel?
>
>> I don't
>>know where you get the "many more than just three
>>channels", because the only common formats are either 3
>>color or 4 color, not "many more than just three.
>
>You've never used Photoshop, have you?
>
>>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.
>
>>I do not know what math precision PS uses internally.
>
>Ah, so you really don't know what you're blathering about.
>
>>The claim that it uses 16 bit math for some calculation
>
>Did you forget that you don't know what you're blathering about?
I suspect the problem is that you don't understand what he his
blathering about. Math precision and colour depth are two entirely
different things.
Eric Stevens
Eric Stevens
wrote:
Don't forget that Motorola made an 80 bit Arithmetic Processor Unit
(APU) for use with the 68000 series of CPUs well before the first IBM
PC was built.
Eric Stevens
Paul Furman
> HEMI-Powered wrote:
>>>
>> I just love two guys measuring their dicks in the shower room! Isn't
>> just the tiniest possibility that someone might actually want BOTH a
>> small P& S and a quality DSLR? Dang, got that!
>
> Yes, Jerry, but this has been going on for weeks. Could you and Paul
> possibly just refrain from replying to the pest?
I'm trying. That message wasn't clearly part of the pattern and folks
might have thought there was a valid point being made. Hell, there might
even be one but with so much garbage tacked on.
--
Paul Furman
www.edgehill.net
www.baynatives.com
all google groups messages filtered due to spam
Paul Furman
> Paul Furman added these comments in the current discussion du
> jour ...
>
>>>> mark,
>> He's not 'mark', he's the P&S troll posting so many crazy
>> rants in here recently with dozens of different names. Don't
>> take him seriously.
>
> I'm not a big fan of abuse reporting wars, Paul, but if we have a
> nym shifter or a sporger amongst us, wouldn't getting his ass
> removed be better? I understand your point and I thank you, but
> absent a LOT of time looking at headers, how does one figure out
> who is real and who is Memorex here?
I set up a filter, though it does get other legitimate posters so I have
to white-list them. I doubt there is any use in reporting to whatever
his ISP(s) is/are.
--
ChaseGoldwin
>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.
>
>This is NOT the same as the number of bits used in the RGB/CMYK data
>channels used to describe the images.
>
>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.
>
>
>
>Eric Stevens
Not confused at all. What you fail to realize is that the larger the values of
data the more math accuracy is needed to manipulate that data without losing
information from that data. Educate yourself.
(Why do these trolls even bother trying to catch up?)
TrollSpotter
Floyd L. Davidson
>Floyd L. Davidson <fl...@apaflo.com> wrote:
>>rfis...@sonic.net (Ray Fischer) wrote:
>>>peter_k_bryansen <pkbry...@whomsoever.com> wrote:
>>>>On Sun, 16 Nov 2008 17:03:23 -0600, "HEMI-Powered" <no...@none.sn> wrote:
>>>>
>>>>>my point in
>>>>>an earlier reply was that this is a fairly academic debate since
>>>>>this isn't either 1984 or 1995, we now have vastly superior HW
>>>>>architectures, but we are also plagued with O/S and app bloatware
>>>>>so severe that even Moore's Law is overwhelmed.
>>>>
>>>>And that is the point being made. Trying to use software which only has 16-bit
>>>>math as the majority of it's functions (i.e. Photoshop) on 48-bit or 64-bit
>>>>color-depth data, is like going back to 1984.
>>>
>>>Except that PS has 8, 16, or 32-bit math PER CHANNEL on its images.
>>
>>Nonsense. Math is not "per channel".
>
>Of course it is.
I'm sorry, you are unaware of what the terms mean.
>I've CS4 running right in front of me. One can
>easily do operations on single channels or combine them.
You can do math on the data from a channel. The data
can be 8, 16, 32 or 201 bit depth data, but *that* does
*not* describe the precision of whatever math is done on
them. Two distinctly different measures of precision.
>> Bit depth is per
>>channel. It is possible to use 16 bit math (or 64 bit
>>math) on 8 bit depth data or on 32 bit depth data.
>
>Photoshop allows for many channels. Not just the common R, G, &B.
A non sequitur. It makes no difference how many
channels there are, because bit-depth is per channel.
The math precision is *NOT* the bit-depth of the data
channels.
>>The number of bits for math is a measure of math
>>precision when doing calculation.
>
>No kidding?
That is entirely distinct from the data channel bit-depth.
No, not kidding...
>> The number of bits
>>for color is a measure of the color precision when the
>>results of the calculation are saved.
>>
>>Bit depth and math are distinctly *different*.
>
>Idiot.
If you don't understand it, that's fine. Calling people
names because you are lost is not acceptable.
>>>Understand the difference? Three channels times 16 bits per channel
>>>is 48 bits. Of course, these programs support many more than just
>>>three channels, which is why you seldom see "48-bit color".
>>
>>"48-bit color" refers to an RGB image format.
>
>Sometimes. What about 64-bit color? Would you know that that refers
>to CMYK at 16-bits per channel? Or LAB color at 16-bits per channel?
What do you mean "sometimes." 48-bit color refers to an
RGB image format. 64-bit color obviously does not.
What's your point?
>> I don't
>>know where you get the "many more than just three
>>channels", because the only common formats are either 3
>>color or 4 color, not "many more than just three.
>
>You've never used Photoshop, have you?
You've never written a computer program to manipulate
image data, have you... ;-)
>>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 SO. Once again, please... the bit depth of the
data has nothing to do with the math precision. They
are two very distinctly separate issues.
If you want, I or any number of others here can actually
write an article describing what the two are, showing
why they are different. But only a very little bit of
your time spent with google would probably clear it
up...
>>I do not know what math precision PS uses internally.
>
>Ah, so you really don't know what you're blathering about.
You don't even know what math precision is.
>>The claim that it uses 16 bit math for some calculation
>
>Did you forget that you don't know what you're blathering about?
How would *you* know???? ;-)
Floyd L. Davidson
>On 17 Nov 2008 01:26:21 GMT, rfis...@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.
>This is NOT the same as the number of bits used in the RGB/CMYK data
>channels used to describe the images.
>
>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.
That is indeed the part the Ray is not aware of.
Paul Furman
> Hi all,
>
> I need to scan some old films using a 48 bits color depth (in order to keep
> the quality after some graphical process).
Are you sure it really matters? Is this some scientific project or
ordinary pictorial photography? For normal photography, you'd have to be
doing some huge changes to the image for this to make any difference
like fixing wildly underexposed shots. Also it appears what you are
calling 48 & 24 bit are what is more commonly called 8 & 16 bit in
photography. The extra bits can make a difference in raw conversion
because that data is not gamma corrected so there are indeed huge
changes made but even then I'm not entirely convinced that it matters
for anything vaguely in the ballbark of a reasonably well exposed
photograph. If you really really need more significant digits, look at
specialized astrophotography (or possibly HDR) software. In fact making
two scans at different brightness may be the best answer if you are
dealing with extremely contrasty images. Plug those into some HDR
software to boost dynamic range.
> My Canon CS5200F does it well but none of my graphical softwares can handle
> 48 bits picture.
>
> The GIMP 2.6.2 translated my pictures from 48 to 24 bits.
> IrfanView does the same as the GIMP (48 => 24).
> I also tried XnView which is supposed to handle 48 bits pictures but when
> the picture is transfered from the scanner, I get a black screen (I tried
> in 24 bits and got the correct picture so this is really a color depth
> problem).
>
> I heard that the GIMP 2.6.2 was using a module called GECL which handles 48
> bits pictures but I did not find any to configure/activate it : my pictures
> are always handled as 24 bits picture.
>
> I do not want to buy any graphical software because many free ones exist.
>
> => Do you know any free software or plugin which could work with 48 bits
> pictures acquired from a scanner ?
>
> Thanks in advance for your help.
--
Paul Furman
www.edgehill.net
www.baynatives.com
all google groups messages filtered due to spam
Ray Fischer
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?
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
He's still an idiot.
>>>>Understand the difference? Three channels times 16 bits per channel
>>>>is 48 bits. Of course, these programs support many more than just
>>>>three channels, which is why you seldom see "48-bit color".
>>>
>>>"48-bit color" refers to an RGB image format.
>>
>>Sometimes. What about 64-bit color? Would you know that that refers
>>to CMYK at 16-bits per channel? Or LAB color at 16-bits per channel?
>>
>>> I don't
>>>know where you get the "many more than just three
>>>channels", because the only common formats are either 3
>>>color or 4 color, not "many more than just three.
>>
>>You've never used Photoshop, have you?
>>
>>>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?
>>>I do not know what math precision PS uses internally.
>>
>>Ah, so you really don't know what you're blathering about.
>>
>>>The claim that it uses 16 bit math for some calculation
>>
>>Did you forget that you don't know what you're blathering about?
>
>I suspect the problem is that you don't understand what he his
>blathering about. Math precision and colour depth are two entirely
>different things.
Just because you say so?
Heres a clue: Any processor can handle any precision (within the
limits of time and memory).
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
>rfis...@sonic.net (Ray Fischer) wrote:
>>Floyd L. Davidson <fl...@apaflo.com> wrote:
>>>rfis...@sonic.net (Ray Fischer) wrote:
>>>>peter_k_bryansen <pkbry...@whomsoever.com> wrote:
>>>>>On Sun, 16 Nov 2008 17:03:23 -0600, "HEMI-Powered" <no...@none.sn> wrote:
>>>>>
>>>>>>my point in
>>>>>>an earlier reply was that this is a fairly academic debate since
>>>>>>this isn't either 1984 or 1995, we now have vastly superior HW
>>>>>>architectures, but we are also plagued with O/S and app bloatware
>>>>>>so severe that even Moore's Law is overwhelmed.
>>>>>
>>>>>And that is the point being made. Trying to use software which only has 16-bit
>>>>>math as the majority of it's functions (i.e. Photoshop) on 48-bit or 64-bit
>>>>>color-depth data, is like going back to 1984.
>>>>
>>>>Except that PS has 8, 16, or 32-bit math PER CHANNEL on its images.
>>>
>>>Nonsense. Math is not "per channel".
>>
>>Of course it is.
>
>I'm sorry, you are unaware of what the terms mean.
You're not smart enough to be condescending.
>>I've CS4 running right in front of me. One can
>>easily do operations on single channels or combine them.
>
>You can do math on the data from a channel. The data
>can be 8, 16, 32 or 201 bit depth data, but *that* does
>*not* describe the precision of whatever math is done on
>them. Two distinctly different measures of precision.
If there's a 32-bit channel then the math is 32 bits. They might do
extended precision in intermediate steps for some bit depths, but I
doubt it. I suppose I could ask some people at Adobe who I once
worked with, but I don't think it's worth wasting their time on.
>>> The number of bits
>>>for color is a measure of the color precision when the
>>>results of the calculation are saved.
>>>
>>>Bit depth and math are distinctly *different*.
>>
>>Idiot.
>
>If you don't understand it, that's fine.
If you're an idiot you're going to pretend that the obvious is deeply
significant.
>>>>Understand the difference? Three channels times 16 bits per channel
>>>>is 48 bits. Of course, these programs support many more than just
>>>>three channels, which is why you seldom see "48-bit color".
>>>
>>>"48-bit color" refers to an RGB image format.
>>
>>Sometimes. What about 64-bit color? Would you know that that refers
>>to CMYK at 16-bits per channel? Or LAB color at 16-bits per channel?
>
>What do you mean "sometimes."
sometimes:
adverb
occasionally, rather than all of the time
> 48-bit color refers to an
>RGB image format.
Unless it doesn't.
> 64-bit color obviously does not.
Unless it does.
>What's your point?
RGB+Alpha. 64 bits per pixel.
>>> I don't
>>>know where you get the "many more than just three
>>>channels", because the only common formats are either 3
>>>color or 4 color, not "many more than just three.
>>
>>You've never used Photoshop, have you?
>
>You've never written a computer program to manipulate
>image data, have you... ;-)
Not since I was a graduate student.
>>>I do not know what math precision PS uses internally.
>>
>>Ah, so you really don't know what you're blathering about.
>
>You don't even know what math precision is.
It is not possile to have a graduate degree in computer science
without knowing more about computer precision in doing math
calculations than you possibly understand.
--
Ray Fischer
rfis...@sonic.net
Eric Stevens
Because I'm ahead of you. But having an APU with the ability to handle
lots of bits in its calculations doesn't mean that you suddenly have
colour channels with gazillion bit capabilities.
Eric Stevens
Eric Stevens
Davidson) wrote:
>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>On 17 Nov 2008 01:26:21 GMT, rfis...@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.
>
>>This is NOT the same as the number of bits used in the RGB/CMYK data
>>channels used to describe the images.
>>
>>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.
>
>That is indeed the part the Ray is not aware of.
That was really what I was trying to tell him.
Eric Stevens
Eric Stevens
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.
Eric Stevens
Eric Stevens
How many bits does a math processor need to handle for it to be able
to deal with the Encyclopaedia Brittanica?
>
>>>>I do not know what math precision PS uses internally.
>>>
>>>Ah, so you really don't know what you're blathering about.
>>>
>>>>The claim that it uses 16 bit math for some calculation
>>>
>>>Did you forget that you don't know what you're blathering about?
>>
>>I suspect the problem is that you don't understand what he his
>>blathering about. Math precision and colour depth are two entirely
>>different things.
>
>Just because you say so?
Yes, especially when I talk about my own suspicions.
>
>Heres a clue: Any processor can handle any precision (within the
>limits of time and memory).
And what has that got to do with the number of bits used to code an
image data channel?
Eric Stevens
Steve
>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.
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.
If you break up your 48 bits of color depth pictures into individual
channels, 32 bit floating point math should be enough if the math
engine is implemented correctly. I.e., it does proper rounding at
each intermediate stage and any time you want to convert back to
integer. But carrying through the extra couple of bits is a good
thing.
Going to double precision (64 bit floating point math) is a waste of
time (literally) in this instance.
Now for the caveat I mentioned above: I've seen quite a few
implementations of math routines where order of processing, incorrect
rounding, etc., all take their toll on the precision/accuracy of the
result when theoretically it should not. I've seen signal processing
routines that work on 16 bit signed integer input data using 32 bit
floating point math that give a different result if you change the
math to 64 bit floating point. Just compiling the routine using 2
different compilers changes the results. In a perfect world that
should not happen. But it does.
Steve
Steve
On 17 Nov 2008 07:12:40 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>If there's a 32-bit channel then the math is 32 bits. They might do
Which, of course, is meaningless unless you define the format of the
32 bits. I.e., if you have 32 bit integer data, you cannot do 32
floating point math on it and expect to keep the level of precision
through even the first calculation that is present in the input data.
Steve
Ray Fischer
> fl...@apaflo.com (Floyd L. Davidson) wrote:
>>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>>On 17 Nov 2008 01:26:21 GMT, rfis...@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.
--
Ray Fischer
rfis...@sonic.net
Steve
Well, not quite. The 80 bit coprocessor for the 68000 series (68881)
wasn't even anounced until a year after the first IBM PC's were
already in use.
Steve
Ray Fischer
>>>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?
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
>
>On Mon, 17 Nov 2008 16:45:50 +1300, Eric Stevens
><eric.s...@sum.co.nz> 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.
--
Ray Fischer
rfis...@sonic.net
Steve
On Sun, 16 Nov 2008 16:57:35 -0600, "HEMI-Powered" <no...@none.sn>
wrote:
>nospam added these comments in the current discussion du jour
>...
>
>> In article <oo01i4lvac2p30o1c...@4ax.com>, mark
>> raif <mark...@privatedomain.net> wrote:
>>
>>> 32-bit math has been around since Windows 3.1
>>
>> 32 bit math was available *long* before that.
>
>In the world of computer science or PCs? I programmed on a 60-bit
>word CDC mainframe for a number of years from the late 1970s to
>1985 when I went over to the Dark Side and became a
>supervisor.Those things were fantastic with at least 11 decimal
>digits of precision after the decimal point. CDC originally was
>formed to build computers for DoD that could do floating point far
>more quickly than the IBMs of the day that needed double-precision
>in SW that was inherently very slow.
Back in the day when I was a DoD engineer, I had my own Cyber 170
running NOS to play with. Of course, the laptop I'm using to write
this can run rings around that thing.
Steve
Ray Fischer
> rfis...@sonic.net (Ray Fischer) wrote:
>>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>> rfis...@sonic.net (Ray Fischer) wrote:
>>>>Floyd L. Davidson <fl...@apaflo.com> 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".
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
32 bits is still 32 bits whether it's foating point or fixed point or
integer.
You don't know what it means to maintain precision so I suggest that
you stop worrying about it and leave it to us computer professionals.
--
Ray Fischer
rfis...@sonic.net
Steve
On 17 Nov 2008 09:44:04 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>Steve <st...@example.com> wrote:
>>
>>On Mon, 17 Nov 2008 16:45:50 +1300, Eric Stevens
>><eric.s...@sum.co.nz> 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.
Ok, but for unnormalized (denormalized, non-normalized, whatever you
want to name it) it's 23. I.e., they stole the sign bit from the
fraction, not the exponent.
The IEEE 754 floating point format only has 23 bits of fraction, not
24. 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.
>>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.
Yup. As I said in my post you responded to, using floating point math
will often give different answers using even the same source code on a
different compiler. In theory, it's possible to carry only one extra
bit of significance through the calculations. In practice, not so
easy.
Steve
Steve
Well, now it's completely obvious that you have no idea what you're
talking about. If you think it's possible to take 32 bit integer data
where the greatest values are higher than 2^24, convert it to 32 bit
floating point, do some calculations on it, then convert back to
integer and get the same results as if you had performed integer
calculations then you are sadly mistaken.
If you're a computer professional, I certainly hope I never come
across anything you've created.
Steve
Steve
On Mon, 17 Nov 2008 10:14:45 GMT, Steve <st...@example.com> wrote:
>
>On 17 Nov 2008 09:49:06 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>
>>Steve <st...@example.com> wrote:
>>> rfis...@sonic.net (Ray Fischer) wrote:
>>>
>>>>If there's a 32-bit channel then the math is 32 bits. They might do
>>>
>>>Which, of course, is meaningless unless you define the format of the
>>>32 bits. I.e., if you have 32 bit integer data, you cannot do 32
>>>floating point math on it and expect to keep the level of precision
>>>through even the first calculation that is present in the input data.
>>
>>32 bits is still 32 bits whether it's foating point or fixed point or
>>integer.
>>
>>You don't know what it means to maintain precision so I suggest that
>>you stop worrying about it and leave it to us computer professionals.
>
>Well, now it's completely obvious that you have no idea what you're
>talking about. If you think it's possible to take 32 bit integer data
>where the greatest values are higher than 2^24, convert it to 32 bit
>floating point, do some calculations on it, then convert back to
>integer and get the same results as if you had performed integer
I should have said ^and always get the same results^ above. Because
I'm sure Mr. Fischer would come up with some special case where the
results would be the same.
J. Clarke
> Eric Stevens <eric.s...@sum.co.nz> wrote:
>> rfis...@sonic.net (Ray Fischer) wrote:
>>> Eric Stevens <eric.s...@sum.co.nz> 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.
--
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
J. Clarke
I note that you do not say "not since I got my doctorate". So you
didn't impress your graduate committed any better than you're
impressing us?
>>>> I do not know what math precision PS uses internally.
>>>
>>> Ah, so you really don't know what you're blathering about.
>>
>> You don't even know what math precision is.
>
> It is not possile to have a graduate degree in computer science
> without knowing more about computer precision in doing math
> calculations than you possibly understand.
Perhaps it is not, so one must conclude that you do not have such a
degree.
bugbear
> => Do you know any free software or plugin which could work with 48 bits
> pictures acquired from a scanner ?
Cinepaint
BugBear
Paul Furman
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."
Ray Fischer
Ray Fischer
>
>On 17 Nov 2008 09:44:04 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>
>>Steve <st...@example.com> wrote:
>>>
>>>On Mon, 17 Nov 2008 16:45:50 +1300, Eric Stevens
>>><eric.s...@sum.co.nz> 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.
>
>Ok, but for unnormalized (denormalized, non-normalized, whatever you
>want to name it) it's 23. I.e., they stole the sign bit from the
>fraction, not the exponent.
True, but FP numbers are almost always normalized.
>The IEEE 754 floating point format only has 23 bits of fraction, not
>24.
Plus a leading 1 bit.
> 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.
>>>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.
>
>Yup. As I said in my post you responded to, using floating point math
>will often give different answers using even the same source code on a
>different compiler. In theory, it's possible to carry only one extra
>bit of significance through the calculations. In practice, not so
>easy.
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
> rfis...@sonic.net (Ray Fischer) wrote:
>>Steve <st...@example.com> wrote:
>>> rfis...@sonic.net (Ray Fischer) wrote:
>>>
>>>>If there's a 32-bit channel then the math is 32 bits. They might do
>>>
>>>Which, of course, is meaningless unless you define the format of the
>>>32 bits. I.e., if you have 32 bit integer data, you cannot do 32
>>>floating point math on it and expect to keep the level of precision
>>>through even the first calculation that is present in the input data.
>>
>>32 bits is still 32 bits whether it's foating point or fixed point or
>>integer.
>>
>>You don't know what it means to maintain precision so I suggest that
>>you stop worrying about it and leave it to us computer professionals.
>
>Well, now it's completely obvious that you have no idea what you're
>talking about.
Except for 30 years as a professional software engineer and a BSCS and
an MSCS. And those three quarters of computer architecture courses
must have been worth something.
> If you think it's possible to take 32 bit integer data
>where the greatest values are higher than 2^24, convert it to 32 bit
>floating point, do some calculations on it, then convert back to
>integer and get the same results as if you had performed integer
Strawman. I never wrote any such thing.
>If you're a computer professional, I certainly hope I never come
>across anything you've created.
You have. I guess that it's running on your computer at this very
moment.
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
Didn't do a PhD. Stanford is very much oriented towards theoretical
computer science while I'm more interested in software engineering.
I stopped with my MSCS.
>>>>> I do not know what math precision PS uses internally.
>>>>
>>>> Ah, so you really don't know what you're blathering about.
>>>
>>> You don't even know what math precision is.
>>
>> It is not possile to have a graduate degree in computer science
>> without knowing more about computer precision in doing math
>> calculations than you possibly understand.
>
>Perhaps it is not, so one must conclude that you do not have such a
>degree.
Or one can conclude that you're an idiot who makes incorrect
assumptions.
--
Ray Fischer
rfis...@sonic.net
Eric Stevens
All I can say is that that wasn't my experience about 1980ish.
Eric Stevens
Eric Stevens
I am an engineer with all that that entails with an interest in
numerical computation. 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 .... . My programs worked which seems to make a
nonsense of your claim that I have very little idea of how computers
do math.
Eric Stevens
Eric Stevens
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"?
Eric Stevens
Eric Stevens
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.
See http://en.wikipedia.org/wiki/Intel_8087
http://en.wikipedia.org/wiki/Motorola_68881
Eric Stevens
Eric Stevens
Actually, I think they were both announced in 1981. I do remember that
Cromemco had 68000 based machines already available at the time of the
IBM announcement (August 81).
Eric Stevens
Steve
On 17 Nov 2008 18:43:29 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>Steve <st...@example.com> 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. 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....
You can run the same program on different hardware and get different
results.
Steve
Doug McDonald
>
> Don't forget that Motorola made an 80 bit Arithmetic Processor Unit
> (APU) for use with the 68000 series of CPUs well before the first IBM
> PC was built.
Well, yes. But Intel made an 80 bit Arithmetic Processor Unit
(APU) for use with the 8086 series of CPUs well before the first IBM
PC was built.
Doug McDonald
Steve
On 17 Nov 2008 18:46:21 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>Steve <st...@example.com> wrote:
>> rfis...@sonic.net (Ray Fischer) wrote:
>>>Steve <st...@example.com> wrote:
>>>> rfis...@sonic.net (Ray Fischer) wrote:
>>>>
>>>>>If there's a 32-bit channel then the math is 32 bits. They might do
>>>>
>>>>Which, of course, is meaningless unless you define the format of the
>>>>32 bits. I.e., if you have 32 bit integer data, you cannot do 32
>>>>floating point math on it and expect to keep the level of precision
>>>>through even the first calculation that is present in the input data.
>>>
>>>32 bits is still 32 bits whether it's foating point or fixed point or
>>>integer.
>>>
>>>You don't know what it means to maintain precision so I suggest that
>>>you stop worrying about it and leave it to us computer professionals.
>>
>>Well, now it's completely obvious that you have no idea what you're
>>talking about.
>
>Except for 30 years as a professional software engineer and a BSCS and
>an MSCS. And those three quarters of computer architecture courses
>must have been worth something.
Apparently not.
>> If you think it's possible to take 32 bit integer data
>>where the greatest values are higher than 2^24, convert it to 32 bit
>>floating point, do some calculations on it, then convert back to
>>integer and get the same results as if you had performed integer
>
>Strawman. I never wrote any such thing.
You certainly implied it when you said "32 bits is still 32 bits
whether it's foating point or fixed point or integer." as a reponse to
me writing that just saying you're doing "32 bit math" is meaningless
unless you define the format.
32 bits is 32 bits only to someone who's worried about storage space,
network mandwidth, etc. To someone who's worried about doing math on
those bits, you MUST know what those bit represent. So just saying
that if "there's a 32 bit channel then the math is 32 bits" is
meaningless without defining what those 32 bits represent. It could
be integer, scaled integer, floating point, etc., all of which are
completely different to a real software engineer.
>>If you're a computer professional, I certainly hope I never come
>>across anything you've created.
>
>You have. I guess that it's running on your computer at this very
>moment.
Ah, judging by the quality of some of the software out there, I
wouldn't doubt it.
Steve
Steve
On Tue, 18 Nov 2008 10:39:46 +1300, Eric Stevens
<eric.s...@sum.co.nz> wrote:
Well, it wasn't quite a year later but it was later. I still have a
magazine where they announced a 68881. It was Feb 1982. The IBM PC
was August 1981.
Steve
Ray Fischer
>On 17 Nov 2008 09:38:29 GMT, rfis...@sonic.net (Ray Fischer) wrote:
>
>>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>> fl...@apaflo.com (Floyd L. Davidson) wrote:
>>>>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>>>>On 17 Nov 2008 01:26:21 GMT, rfis...@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.
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
What kind of engineer?
> 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.
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
> rfis...@sonic.net (Ray Fischer) wrote:
>>Steve <st...@example.com> 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
rfis...@sonic.net
Ray Fischer
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
rfis...@sonic.net
Ray Fischer
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.
Ancient history.
--
Ray Fischer
rfis...@sonic.net
Ray Fischer
> rfis...@sonic.net (Ray Fischer) wrote:
>>Steve <st...@example.com> wrote:
>>> rfis...@sonic.net (Ray Fischer) wrote:
>>>>Steve <st...@example.com> wrote:
>>>>> rfis...@sonic.net (Ray Fischer) wrote:
>>>>>
>>>>>>If there's a 32-bit channel then the math is 32 bits. They might do
>>>>>
>>>>>Which, of course, is meaningless unless you define the format of the
>>>>>32 bits. I.e., if you have 32 bit integer data, you cannot do 32
>>>>>floating point math on it and expect to keep the level of precision
>>>>>through even the first calculation that is present in the input data.
>>>>
>>>>32 bits is still 32 bits whether it's foating point or fixed point or
>>>>integer.
>>>>
>>>>You don't know what it means to maintain precision so I suggest that
>>>>you stop worrying about it and leave it to us computer professionals.
>>>
>>>Well, now it's completely obvious that you have no idea what you're
>>>talking about.
>>
>>Except for 30 years as a professional software engineer and a BSCS and
>>an MSCS. And those three quarters of computer architecture courses
>>must have been worth something.
>
>Apparently not.
Given your limited understanding you're hardly in any position to
know.
>>> If you think it's possible to take 32 bit integer data
>>>where the greatest values are higher than 2^24, convert it to 32 bit
>>>floating point, do some calculations on it, then convert back to
>>>integer and get the same results as if you had performed integer
>>
>>Strawman. I never wrote any such thing.
>
>You certainly implied it
Don't start lying about what I write. I did NOT imply anything of the
sort. It is all YOUR limited understanding.
>32 bits is 32 bits only to someone who's worried about storage space,
>network mandwidth, etc.
Tell us which is faster: 8-bit, 16-bit, 32-bit, or 64-bit integer
math?
> To someone who's worried about doing math on
>those bits, you MUST know what those bit represent. So just saying
>that if "there's a 32 bit channel then the math is 32 bits" is
>meaningless without defining what those 32 bits represent.
LOL! You're stuck on the data representation and completely ignoring
the algorithm.
> It could
>be integer, scaled integer, floating point, etc., all of which are
>completely different to a real software engineer.
And how would you know?
By the way: "Scaled integer"? No such thing. Unless you meant fixed
point?
>>>If you're a computer professional, I certainly hope I never come
>>>across anything you've created.
>>
>>You have. I guess that it's running on your computer at this very
>>moment.
>
>Ah, judging by the quality of some of the software out there, I
>wouldn't doubt it.
Stupid asshole.
--
Ray Fischer
rfis...@sonic.net
Eric Stevens
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
Eric Stevens
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