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