Wolfgang Köhler wrote:
> One minor question remains for me, but I'm not sure if you can help me.
>
> If I set the scan width above 800 (say 1000) (in the 8-bit grey mode, 300 dpi)
> the scanning speed slows down remarkably, and the scanner bar seems to
> oscillate back and forth. The output is ok, however.
I guess this could be a side effect of the scanner buffer being too
small to contain the number of pixels you specify in your scan command.
Basically the scanner has a linear ccd sensor. In front of this sensor
there are filters (coated on top of the silicon) for each primary colour
(red, green and blue, or alternatively (rarely) cyan, yellow and
magenta).
Because there can't be three filters in front of ONE pixel, the ccd has
different pixels for red, green and blue. There are two (actually there
are a few more arrangements) possible ways to arrange these pixels:
graphically depicted as follows:
1) one line of pixels: (interdigitated)
RGBRGBRGBRGBRGB....RGB
2) three lines of pixels: (tri-linear)
RRRRRRRRRRRRRRRR...RRR
GGGGGGGGGGGGGGGG...GGG
BBBBBBBBBBBBBBBB...BBB
the second option is the most common because it's easier to make, the
filters are easier to align, and because it has (given a certain
manufacturing technology) a higher resolution. It has one disadvantage:
there has to be a physical gap of four or eight pixels in the scan
direction between the lines (room for the readout circuitry associated
with the pixels); this means that given a certain sensor position
relative to the paper, each line sees a slightly different piece of the
document. This problem can be amended through software though. In *SOME*
cases this is done within the scanner by a piece of software called
firmware. To do this the firmware buffers the digitized pixel values
internally.
Let's assume the scanner has a sensor with 4 lines in between the red
and green row of pixels, and 4 lines between the green and blue line
(and thus 8 lines between the red and blue line). This means that it has
to store 1 line of red, 5 lines of green and 9 lines of blue before it
can output a single line of RGB data to the scsi bus. This is a total of
15 lines. If you have an 8 inch wide piece of paper, with 300 dpi, this
means that you have 2400 pixels on a line, so the scanner needs a buffer
capacity of 2400*15 bytes= 36 kilobytes. Because memory is money, and
manufacturers do not want to spend to much on it, *SOME* scanners do NOT
have this much (or little) (sometimes the memory is even actually
present, but because the designer did not allocate an extra physical
address pin on the asic (application specific integrated circuit)
commonly used to glue the components together, it just can not be
addressed; and redesigning an asic is NOT cheap (and having to use an
asic with 128 pins instead of 84 pins because that's the next available
packaging option isn't cheap either)).
Now what if memory is insufficient? then the scanner has to read as many
pixels as it can (lets say 800) transfer these to the computer, move the
scan head back to the position it should be in to see the next chunk of
pixels (lets say 20), and then transfer these last (20) pixels. All this
depends on the output format of the data. If the scanner transfers the
data as RGB pixels, this would be the case. If this is the case, and the
scanner slows down if the width is more than 800 pixels, another
decrease in speed can be expected at 1600 and 2400 pixels.
If on the other hand the scanner transfers pixels in a line-sequential
way (first a line of red bytes, then a line of green bytes, then a line
of blue bytes), there is another option: then the scanner could first
read in the red line, transfer these, move forward 4 steps, read in the
green line, transfer these, move forward 4 steps, read in the blue line,
transfer these, and then move BACK seven steps (move back eight steps to
move the red line to it's original position, then forward one step to
move to the next line of the document.
Now why does this increase scanning time? Because under normal
circumstances the hardware transfers pixels out of the sensor array at a
certain fixed rate (typically 1.5 Mpixel per second), and HAS to
transfer a whole line (let's say 2700 pixels for a typical sensor chip
such as the sony ILX533 (you can look up the specs on the sony
web-site)) at a time (while immediately discarding the pixels it does
not need or can't cope with). Normally the scanner would read in the R,G
and B pixel values in parallel, but if it can't, it has to do this
sequentially. If this is the case, this would lead to a threefold
decrease in scanning speed. Besides this, the scanner needs time to
reposition it's head mechanically.
The repositioning has the side effect of increasing noise production.
To make this story complete: some scanners have a sensor chip that
supports an operational mode called "binning" in this mode two adjacent
pixels are added together, halving the *optical* resolution, but
increasing scanning speed (twofold). The (typical) ILX533 does NOT have
this option.
Now this may be the answer to your question, and it may apply to some
other scanners as well, but not necessarily. My own scanner (scanmaker
III) does not rearrange the lines internally; it just ignores the lines
it can't handle. The output format of this scanner is as follows:
line output DATA line scanned
1 red 1 green and blue ignored
2 red 2 green and blue ignored
3 red 3 green and blue ignored
4 red 4 blue ignored
5 green 1 blue ignored
6 red 5 blue ignored
7 green 2 blue ignored
8 red 6 blue ignored
9 green 3 blue ignored
10 red 7
11 green 4
12 blue 1
13 red 8
14 green 5
15 blue 2
16 red 9
17 green 6
18 blue 3
.
.
n red (n-1)/3+4
n+1 green (n-1)/3+1
n+2 blue (n-1)/3-2
.
.
3m-11 red m
3m-10 green m-3
3m-9 blue m-6
3m-8 green m-2 red ignored
3m-7 blue m-5 red ignored
3m-6 green m-1 red ignored
3m-5 blue m-4 red ignored
3m-4 green m red ignored
3m-3 blue m-3 red ignored
3m-2 blue m-2 red and green ignored
3m-1 blue m-1 red and green ignored
3m blue m red and green ignored
(scanning m lines, transferring 3m lines of data (each R, G, and B seen
as a different line))
This means the reshuffling has to be done by the scanner driver
software! (which it does)
now this is all just an educated guess. (I'm an electronic engineer, and
have designed and constructed a special purpose scanner myself (from
scratch), so I had to dive deep into this subject)
do you think it is useful if I write a few more "tutorials" about the
electronic and mechanical innards of scanners, the SCSI bus and
associated subjects, bundle them into a "FAQ" and put them on a web
site, or would that be a waste of time? does anyone have any specific
question?
regards, Theo.
Theo Borm
borm@xs4all.nl
+31-317-420702
+31-317-414936
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com