SCSI - Small Computers System Interface
SCSI2 scanners
In the second half of the '80s scanners started invading the market. The
problem with them was the interface they used to connect to the PC.
These were the interfaces used in that epoch:
- GP-IB (Sharp)
- bidirectional parallel port (Epson)
- proprietary interface (HP)
- video interface (many different brands)
Proprietary interface and parallel port were used by low cost scanners.
All the high performance scanners, instead, used the so called video
interface, and this meant that you had to pay an expensive interface
card in addition to the already expensive scanner.
Low cost scanners were slow, good for personal use, and all the resources
they used to operate were the resources of the PC they were connected to.
The resources of an 80386 PC weren't enough, instead, to support the needs
of scanners that could scan 20/30 pages per minute, so these scanners
required the video interface cards. This interfaces had their own CPU, RAM
and firmware, and were true computers that you put into the PC. Xionics
and Kofax were the most used video interface cards used by programmers for
their optical storage applications.
Fortunately in the first half of the '90s SCSI2 scanners appeared on the
market. In the meantime PCs moved to 486/66 and Pentium 75 CPUs, and were
rich of resources and fast enough to compress/decompress images at a rate
of 10 images per minute.
SCSI2 scanners reduced the cost of the hardware required for each
installation, provided the programmer had his own software to perform
image management activities. I wrote all my DOS/asm routines to manage
display, compression, decompression, and so forth (a difficult thing to
get was a copy of the T.6 recommendation from CCITT, the document which
explained the standard group IV-2d image compression).
You might choose to deal with a SCSI2 scanner by means of its TWAIN driver,
it's a good choice. But you can also send it your own SCSI2 commands by
means of an ASPI driver to get faster performance.
We will now talk about the scanners that support only the mandatory SCSI2
commands, and eventually the Object Position command.
Making a SCSI2 scanner scan a page for you is as easy as send it the
following commands: Test Unit Ready, Object Position, Set Window and Read.
Let's revise each command.
Test Unit Ready: this is a preliminary command to check whether
the scanner is ready to receive further commands. Send this command,
and any subsequent SCSI2 command, by means of an Exec SCSI2 command
ASPI command. (There is no play on words, please keep distinguished
SCSI2 commands from ASPI commands; see this
article). If the ASPI command returns something different from
SS_COMP you have to check the sense data to discover why the
scanner was not ready.
Object Position: this is an optional SCSI2 command supported by
those scanners which offer two possibilities:
- scanning from the flatbed (a plain glass surface)
- scanning from the automatic document feeder (ADF for short)
Usually you get an error from this command if you select to scan from
the ADF and this latter is empty.
Set Window: this command lets you define a window over the document
that is going to be scanned. Only the portion of the document that falls
into the window will be scanned. To set the window you have to prepare
a structured buffer of data with the following parameters: the scanning
resolution, the scanning window definition, the threshold and the number
of bit per pixels.
The scanning resolution can be individually set for each scanning axis.
The scanning window is supplied by means of its width, height, and offset
from the origin of the flatbed. The threshold is the limit at which the
scanner discriminates a pixel being of one colour or not. The number of
bit per pixels defines the number of gray levels (or colours) to use: one
bit per pixel would mean a black and white image.
Read: before issuing a Read command you should first calculate
the number of bytes that you must read from the scanner. Then you should
read not more nor less than the calculated amount of bytes, differently
you can easily imagine that some problems will soon occur.
The number of bytes to read from the scanner depends on the width and the
height of the scan window, the scan resolution, and the number of requested
bit per pixel. A window of 11 by 8 inches at 200 dpi and one bit per pixel
would mean 440,000 bytes to read.
If you try to read more than 440,000 bytes your program will stall waiting
for bytes that the scanner will never give it back. If you read less than
440,000 bytes this time the program will not stall, but will stall at the
next scan. Infact the scanner is waiting for the program to ask it the
remainder of the bytes from the previous scan, and receives instead new
commands for a new scan operation. There is not anything more confusing
the scanner than this situation. The final result is that the scanner
stalls and the program in turn.
The bytes read from the scanner must be accomodated in a frame
buffer, a memory area used for subsequent image manipulation.
The scanner to choose depends on the application requirements in terms
of speed and allowable paper size.
For a basic professional use I suggest Fujitsu ScanPartner SP300C.
It is cheap, offers both flatbed and ADF object positions, and a scan speed
of ten pages per minute. Furthermore it benefits from a 3 years on site
service guarantee. SP300C is a colour scanner. It replaces (and enhances)
its predecessor SP10.
Other good scanners are the Bell+Howell 2000F and the Fujitsu
ScanPartner SP620C. They are perfectly interchangeable with the models
in the Fujitsu ScanPartner family, the only difference is that 2000F and
620C are twice faster (and cost a bit more...).
I recently discovered that the above scanners (Fusjitsu and Bell+Howell) are
actually manufactured by Avision (check their
site). Avision SCSI2 scanners models:
- AV-810: 10 pages per minute, flatbed, ADF 50 sheets
- AV-820: 20 pages per minute, flatbed, ADF 50 sheets
- AV-830: 30 pages per minute, flatbed, ADF 50 sheets
All these Avision scanners are cheaper that the similar models remarketed by
Fujitsu and Bell+Howell.
|