-----Ursprungligt meddelande-----
Från: filmscanners_Digest_owner@halftone.co.uk
[mailto:filmscanners_Digest_owner@halftone.co.uk]
Skickat: den 23 mars 2003 01:00
Till: tibor@home.se
Ämne: [filmscanners_Digest] filmscanners Digest for Sun 23 Mar, 2003
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Topic: [filmscanners] RE:
====================
Date: Sat, 22 Mar 2003 13:37:07 -0800
From: Roy Harrington <roy@harrington.com>
----------------------------------------
on 3/22/03 12:51 AM, Paul D. DeRocco at pderocco@ix.netcom.com wrote:
>> From: Roy Harrington
>>
>> Interesting. Maybe they figured there was a possibility of color
>> artifacts showing up. I assume you mean an RGB where R=G=B ? If
>> they were different the dithering would have to be different, too,
>> wouldn't it?
>
> I think the noise added to the three values is the same. If the
> fractional bits of the three colors are different, then how the three
> values round off to eight bits would vary among the colors.
Good call, Paul. I decided to try this with an RGB of (50.2, 50.4,
50.6). Sure enough all three colors dither between 50 and 51, but R=51
is a direct subset of G=51 which in turn is a direct subset of B=51.
I think this rules out any of the more advanced dithering algorithms
like diffusing the error as you go -- i.e. each pixel is independent.
>
> If the difference were at all visible, which I doubt, I think having
> the colors separately dithered would be a slight improvement, for the
> same reason that an B&W image printed on an inkjet appears less grainy
> when printed with CMY dots rather than just black dots.
Don't know Adobe's reasons, but I think introducing color no matter how
little would be a no no. If someone had a pure gray 16bit RGB file and
conversion to 8bit added color, I'd hate to be the one trying to justify
that. It may be minor to start with, but with sharpening and other
filters who knows.
>
>
> --
>
> Ciao, Paul D. DeRocco
> Paul mailto:pderocco@ix.netcom.com
>
Roy
Roy Harrington
roy@harrington.com
Black & White Photography Gallery
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] RE: 8bits
==========================
Date: Fri, 21 Mar 2003 18:19:33 -0800
From: Roy Harrington <roy@harrington.com>
----------------------------------------
on 3/21/03 10:58 AM, Paul D. DeRocco at pderocco@ix.netcom.com wrote:
>> From: Roy Harrington
>>
>> I tried your particular construction and by sheer coincidence the
>> numbers you get happen to be an almost exact match of 16 bit versus 8
>> bit. 0xAAAA is the exact mapping of 0xAA so when you converted, it
>> was extremely close. When I tried it I actually got .26% of the
>> pixels to come out 169 with the rest all being 170.
>>
>> 8 bit goes from 0 to 255 (in hex 0xFF)
>> 16 bit goes from 0 to 65535 (in hex 0xFFFF)
>>
>> Both the black and the white points must match in mapping, 0 to 0 is
>> trivial but 65535/255 = 257 so you need to multiply 255 by 257 to
>> convert from 8 to 16 bit.
>
> You're right! I had assumed that they divided by 256, not 257. I stand
> corrected. When I repeated the test to produce numbers that are not
> multiples of 257, it did indeed do some dithering.
>
> What's odd is that in RGB mode it dithers all the colors with the same
> pattern. You'd think they'd use uncorrelated dither noise for the
> three colors.
Interesting. Maybe they figured there was a possibility of color
artifacts showing up. I assume you mean an RGB where R=G=B ? If they
were different the dithering would have to be different, too, wouldn't
it?
>
>> Here's a much easier construction that will show what you want. Fill
>> the canvas in 8 bit mode -- say Gray=128. Convert to 16 bit now you
>> have an exact 16bit representation of an 8bit value. Now do a very
>> minor Levels change. Set the white point from 255 to 254. That will
>> nudge every gray value X = X*(255/254). So 128 will go up by a half,
>> if you had picked Gray = 85 to start it would go up by a third, ...
>> etc.
>>
>> Now convert to 8-bit and see the dithered pixels.
>
> What I'd like to know is how you managed to convert from 8bpc to
> 16bpc. You must have a different version of PS, because mine doesn't
> let you do that. I'm using v7.01 for Windows.
That's strange. I've always been able to change the mode to 16bit. You
can't have any layers of course. I'm using PS 6 and 7 on both Mac OS 9
and OS X.
>
> --
>
> Ciao, Paul D. DeRocco
> Paul mailto:pderocco@ix.netcom.com
>
Roy
Roy Harrington
roy@harrington.com
Black & White Photography Gallery
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] RE: 8bits vs. ==============================
Date: Fri, 21 Mar 2003 10:05:09 -0800
From: Roy Harrington <roy@harrington.com>
----------------------------------------
on 3/21/03 12:22 AM, Paul D. DeRocco at pderocco@ix.netcom.com wrote:
>> From: Roy Harrington
>>
>> Did you see my example showing that PS does in fact do more than just
>> truncating 16 bits to 8 bits? PS in a 16 to 8 bit mode change
simulates
>> intermediate values by dithering exactly like the gradient tool does.
>> I don't know whether it's done by adding noise and truncating or a
>> more elaborate algorithm but PS does make the average 8 bit gray
>> value keep as much of the 16bit data that it can.
>
> How did you get it to do this? Here's the experiment I performed.
>
> 1) Since PS doesn't let you create a 16bpc image from scratch or
> up-convert an 8bpc image, I opened an existing 16bpc TIFF file.
>
> 2) Since PS won't let you fill a 16bpc image, I used Levels to squeeze
> the entire dynamic range down to nothing, by setting the Output Levels
> range to 128 to 128. That gave me a uniform gray.
>
> 3) I used Levels again to stretch the dynamic range by setting the
> Input Levels range to 126 to 129. This converts the value 128 into 2/3
> of full scale, or 170 on an 8-bit scale, but with some fractional
> bits.
>
> 4) I saved it with no compression, and opened the file in a hex
> editor. The 16bpc values were all 0xAAA9, proving that it did indeed
> have fractional bits.
>
> 5) I converted the image to 8bpc. Moving the cursor over it still
> showed a value of 170 on every pixel.
>
> 6) I resaved it, and the hex editor showed the 8bpc values as all
> being 0xAA.
>
> If it had dithered, I would expect 2/3 of the values to be 171, or
> 0xAB.
>
> --
>
> Ciao, Paul D. DeRocco
> Paul mailto:pderocco@ix.netcom.com
>
I tried your particular construction and by sheer coincidence the
numbers you get happen to be an almost exact match of 16 bit versus 8
bit. 0xAAAA is the exact mapping of 0xAA so when you converted, it was
extremely close. When I tried it I actually got .26% of the pixels to
come out 169 with the rest all being 170.
Here's a much easier construction that will show what you want. Fill
the canvas in 8 bit mode -- say Gray=128. Convert to 16 bit now you
have an exact 16bit representation of an 8bit value. Now do a very
minor Levels change. Set the white point from 255 to 254. That will
nudge every gray value X = X*(255/254). So 128 will go up by a half, if
you had picked Gray = 85 to start it would go up by a third, ... etc.
Now convert to 8-bit and see the dithered pixels.
------
I have a feeling my above 8bit to 16bit mapping will raise questions so
I'll run through the logic and an easy way to check it.
8 bit goes from 0 to 255 (in hex 0xFF)
16 bit goes from 0 to 65535 (in hex 0xFFFF)
Both the black and the white points must match in mapping, 0 to 0 is
trivial but 65535/255 = 257 so you need to multiply 255 by 257 to
convert from 8 to 16 bit. So:
X16 = X8 * 257
Its particularly easy to see in hex (if you're into that kind of thing).
0xFF maps to 0xFFFF, 0x12 maps to 0x1212, 0xAA maps to 0xAAAA -- you
just duplicate the top byte into the new bottom byte.
Going the other way you just start with doing the opposite:
X8 = X16 / 257
This is an integer divide i.e. it truncates and leaves a remainder. The
remainder is how far off X8 is from matching the X16 gray value we
really want. So with probability p = (remainder/257) we add one to X8.
This is the dithering step that produces an "average" 8bit gray by using
X8 and X8+1.
------
I've looked at the output from PS by using the Raw output format and a
hex dump to confirm this. There is one other very minor (but to be
exact I'll mention it) quirk. Internally, PS uses just 15 bits of data
in the 16 bit mode -- I believe that this is purely for efficiency
reasons. Because of this whenever you save as TIFF or as Raw the bottom
bit is always fixed. Note that this is a very minor issue and shouldn't
be blown out of proportion, I only mention it because if you look at hex
dumps it'll be obvious.
Roy
Roy Harrington
roy@harrington.com
Black & White Photography Gallery
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] RE: 8bits vs. 16bits/channel:
==============================================
Date: Thu, 20 Mar 2003 22:40:55 -0800
From: Roy Harrington <roy@harrington.com>
----------------------------------------
on 3/18/03 11:28 PM, Paul D. DeRocco at pderocco@ix.netcom.com wrote:
>> From: Austin Franklin
>>
>> Can you give a concrete example of what you believe it does? Do you
>> believe it takes 0x1289 and converts it to 0x13? Let's say the
>> entire image is completely 0x1280...are you believing that ~half the
>> 8 bit data is 0x13 and
>> ~half 0x12? Yes, if you believe that, and can demonstrate it, I'd
like to
>> see it, and I would agree that is dithering. But really, no
>> entire field in
>> real life would consist of 0x1280...there would be a range, and
>> in reality,
>> simply converting by lopping off the 8 LSBs will give you the same
>> "fidelity", from an analysis standpoint.
>
> Photoshop doesn't do this. It optionally adds dither noise when
> creating an artificial gradient, but a simple experiment proved to my
> own satisfaction that merely converting from 16bpc to 8bpc does
> nothing more than truncating each 16-bit value.
>
> --
>
> Ciao, Paul D. DeRocco
> Paul mailto:pderocco@ix.netcom.com
>
Paul,
Did you see my example showing that PS does in fact do more than just
truncating 16 bits to 8 bits? PS in a 16 to 8 bit mode change
simulates
intermediate values by dithering exactly like the gradient tool does. I
don't know whether it's done by adding noise and truncating or a more
elaborate algorithm but PS does make the average 8 bit gray value keep
as much of the 16bit data that it can.
Roy
Roy Harrington
roy@harrington.com
Black & White Photography Gallery
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] Re: 8bits vs.
16bits/channel:cantheeyeseethedifference
=======================================================================
Date: Fri, 21 Mar 2003 00:22:01 -0800
From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
----------------------------------------
> From: Roy Harrington
>
> Did you see my example showing that PS does in fact do more than just
> truncating 16 bits to 8 bits? PS in a 16 to 8 bit mode change
simulates
> intermediate values by dithering exactly like the gradient tool does.
> I don't know whether it's done by adding noise and truncating or a
> more elaborate algorithm but PS does make the average 8 bit gray value
> keep as much of the 16bit data that it can.
How did you get it to do this? Here's the experiment I performed.
1) Since PS doesn't let you create a 16bpc image from scratch or
up-convert an 8bpc image, I opened an existing 16bpc TIFF file.
2) Since PS won't let you fill a 16bpc image, I used Levels to squeeze
the entire dynamic range down to nothing, by setting the Output Levels
range to 128 to 128. That gave me a uniform gray.
3) I used Levels again to stretch the dynamic range by setting the Input
Levels range to 126 to 129. This converts the value 128 into 2/3 of full
scale, or 170 on an 8-bit scale, but with some fractional bits.
4) I saved it with no compression, and opened the file in a hex editor.
The 16bpc values were all 0xAAA9, proving that it did indeed have
fractional bits.
5) I converted the image to 8bpc. Moving the cursor over it still showed
a value of 170 on every pixel.
6) I resaved it, and the hex editor showed the 8bpc values as all being
0xAA.
If it had dithered, I would expect 2/3 of the values to be 171, or 0xAB.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] Re: 8bits
vs.16bits/channel:cantheeyeseethedifference
======================================================================
Date: Fri, 21 Mar 2003 10:58:51 -0800
From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
----------------------------------------
> From: Roy Harrington
>
> I tried your particular construction and by sheer coincidence the
> numbers you get happen to be an almost exact match of 16 bit versus 8
> bit. 0xAAAA is the exact mapping of 0xAA so when you converted, it was
> extremely close. When I tried it I actually got .26% of the pixels to
> come out 169 with the rest all being 170.
>
> 8 bit goes from 0 to 255 (in hex 0xFF)
> 16 bit goes from 0 to 65535 (in hex 0xFFFF)
>
> Both the black and the white points must match in mapping, 0 to 0 is
> trivial but 65535/255 = 257 so you need to multiply 255 by 257 to
> convert from 8 to 16 bit.
You're right! I had assumed that they divided by 256, not 257. I stand
corrected. When I repeated the test to produce numbers that are not
multiples of 257, it did indeed do some dithering.
What's odd is that in RGB mode it dithers all the colors with the same
pattern. You'd think they'd use uncorrelated dither noise for the three
colors.
> Here's a much easier construction that will show what you want. Fill
> the canvas in 8 bit mode -- say Gray=128. Convert to 16 bit now you
> have an exact 16bit representation of an 8bit value. Now do a very
> minor Levels change. Set the white point from 255 to 254. That will
> nudge every gray value X = X*(255/254). So 128 will go up by a half,
> if you had picked Gray = 85 to start it would go up by a third, ...
> etc.
>
> Now convert to 8-bit and see the dithered pixels.
What I'd like to know is how you managed to convert from 8bpc to 16bpc.
You must have a different version of PS, because mine doesn't let you do
that. I'm using v7.01 for Windows.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] Re:
8bitsvs.16bits/channel:cantheeyeseethedifference
=====================================================================
Date: Sat, 22 Mar 2003 00:51:33 -0800
From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
----------------------------------------
> From: Roy Harrington
>
> Interesting. Maybe they figured there was a possibility of color
> artifacts showing up. I assume you mean an RGB where R=G=B ? If they
> were different the dithering would have to be different, too, wouldn't
> it?
I think the noise added to the three values is the same. If the
fractional bits of the three colors are different, then how the three
values round off to eight bits would vary among the colors.
If the difference were at all visible, which I doubt, I think having the
colors separately dithered would be a slight improvement, for the same
reason that an B&W image printed on an inkjet appears less grainy when
printed with CMY dots rather than just black dots.
> That's strange. I've always been able to change the mode to 16bit.
> You can't have any layers of course. I'm using PS 6 and 7 on both Mac
> OS 9 and OS X.
Ahah! The key is layers. When I create a new blank image, it comes out
as having one layer and no background. If I flatten it, then I can
convert to 16bpc. You learn something every day...
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] RE: Adaptec USB2 to SCSI
=========================================
Date: Thu, 20 Mar 2003 22:17:11 -0600
From: "Jeff Scribner" <scribjs@scribnerdesign.com>
----------------------------------------
>Has anyone had experience with using Adaptec's USB2Xchange USB2-to-SCSI
converter to attach and operate LS-30 or other SCSI scanners?<
I own, and have used the USB2->SCSI on my notebook. I was connected to
an Agfa T1200 flatbed. I've also had great luck with a SCSI Zip drive.
Having said that, if you are not connected to notebook, a PCI based scsi
adapter will be cheaper and faster.
Someone mentioned possible problems with Windows XP. I have not used
XP, but I would advise purchasing an Adaptec card. I've owned three or
four over the years, and have never had a problem in any version of NT
or Win2k.
Good Luck,
Jeff
-=-=-=-=-=-==-=-=-=-
Date: Fri, 21 Mar 2003 01:08:16 -0600
From: "LAURIE SOLOMON" <laurie@advancenet.net>
----------------------------------------
Jeff,
I was the one who mentioned problems with XP and PCI bassed SCSI cards.
While I also like and suggest Adaptec cards, I must point out the the
problems encountered were with adaptec cards since they are the only
ones that I own. This is not to say that the cards were the cause of
the problem. I believe than in most cases the problem is with the the
Adaptec ASPI layer primarily. Microsoft at one point refused to license
it from Adaptec and designed their own SCSI driver and ASPI look alike
for WIN XP. This more often then not does not work with older SCSI
devices and third party cards that make use of and require the ASPI
layer. Microsoft and Adaptec, after the release of Win XP, finally came
to an agreement; and Adaptec released an ASPI Layer that would work with
Win XP. Unfortunately, the OS's factsimile ASPI layer which the OS
defaults to does not like to live compatibly with the Adaptec ASPI layer
in the same operating system; and it tends to override the Adaptec ASPI
layer unless one forces the Adaptec layer. Furthermore, some Adaptec
cards ( those with onboard bios) tend to work better in WIN XP systems
than the cards without the onboard bios and tend to find the Adaptec
ASPI layer easier on Win XP systems than is the case for the Adaptec
SCSI cards without onboard bios. This may be because the cards with
internal bios and ability to support a bootable hard drive get
recognized by the motherboard's Bios prior to the loading of Win XP;
whereas, the cards without onboard bios which typically can support
devices like scanners but not bootable drives may not be fully
recognized by the system prior to the loading of Win XP but only get
fully recognized after the loading of Win XP. As a result, WIN XP's
default facsimile ASPI layer gets installed before the Adaptec ASPI
layer in this case, preventing the installation of the Adaptec ASPI
Layer.
Win2K and Win NT did not have the Microsoft factsimile ASPI layer but
used the Adaptec ASPI layer, which is why one may not have encountered
any problem with SCSI drivers, cards and devices with pre WIN XP OSs.
-----Original Message-----
From: filmscanners_owner@halftone.co.uk
[mailto:filmscanners_owner@halftone.co.uk]On Behalf Of
scribjs@scribnerdesign.com
Sent: Thursday, March 20, 2003 10:17 PM
To: laurie@advancenet.net
Subject: [filmscanners] RE: Adaptec USB2 to SCSI
>Has anyone had experience with using Adaptec's USB2Xchange USB2-to-SCSI
converter to attach and operate LS-30 or other SCSI scanners?<
I own, and have used the USB2->SCSI on my notebook. I was connected to
an Agfa T1200 flatbed. I've also had great luck with a SCSI Zip drive.
Having said that, if you are not connected to notebook, a PCI based scsi
adapter will be cheaper and faster.
Someone mentioned possible problems with Windows XP. I have not used
XP, but I would advise purchasing an Adaptec card. I've owned three or
four over the years, and have never had a problem in any version of NT
or Win2k.
Good Luck,
Jeff
------------------------------------------------------------------------
----
------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe
filmscanners' or 'unsubscribe filmscanners_digest' (as appropriate) in
the message title or body
-=-=-=-=-=-==-=-=-=-
Date: Fri, 21 Mar 2003 20:55:00 -0600
From: "Jeff Scribner" <scribjs@scribnerdesign.com>
----------------------------------------
Hi Laurie,
>I was the one who mentioned problems with XP and PCI bassed SCSI
>cards.<
Good stuff to know. I have not installed WinXP, and can't imagine doing
it now as my system is all scsi devices.
Jeff
-=-=-=-=-=-==-=-=-=-
Topic: [filmscanners] Re: JPEG2000 =============================
Date: Fri, 21 Mar 2003 00:24:26 -0800
From: Dieder Bylsma <scanners@spacemoo.com>
----------------------------------------
a query re: JPEG2000. How does Apple's QuickTime JPEG2000 version
compare with the others? Is there a standardized 'comparison' I can
run with a test image to compare for quality of compression,
decompression time etc? So far all the JPEG2000 comments I have seen
seem to be referring to the WinTel/x86 platform?
Dieder
-=-=-=-=-=-==-=-=-=-
Topic: unsubscribe filmscanners
==========================
Date: Fri, 21 Mar 2003 20:56:31 -0600
From: "Jeff Scribner" <scribjs@scribnerdesign.com>
----------------------------------------
unsubscribe filmscanners
-=-=-=-=-=-==-=-=-=-
----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or
body
