sane-project-website/old-archive/1998-03/0112.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>&gt; One minor question remains for me, but I'm not sure if you can help me.</i><br>
<i>&gt; </i><br>
<i>&gt; If I set the scan width above 800 (say 1000) (in the 8-bit grey mode, 300 dpi)</i><br>
<i>&gt; the scanning speed slows down remarkably, and the scanner bar seems to</i><br>
<i>&gt; 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>