# Re: Scan ahead

From: Tom Martone (tom@martoneconsulting.com)
Date: Sat Mar 31 2001 - 09:00:39 PST

- Next message: Henning Meier-Geinitz: "Re: preview and selectable scanarea for MFS-12000's ADF"
  - Previous message: Karsten Festag: "Re: microtek2 and scsi_read_image_status"
  - In reply to: Stephen Williams: "Re: Scan ahead"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Greetings,

  Stephen Williams wrote:
  >
  > peter@kirchgessner.net said:
  > > I dont know a scanner that can store a single frame completely. For an
  > > A4 scan at 600 dpi with 24bit you would need about 100MB of memory.
  >
  > I know several, and they are grayscale and color. And we keep building
  > more because this pipelining really does help when you are talking about
  > large batches. Of course, we are not talking about desk-top flat-bed
  > scanners here:-)

  The Bell+Howell CopiScan series scanners have an Remote SCSI Controller
  that is a little computer with memory sufficient to store images
  and perform operations such as compression, automatic border detection,
  deskew, etc. This is done in b/w at resolutions ~200dpi-400dpi.
  Depending on the size of the pages, there can be room for several
  images in the cache. As the image data is read by the host computer
  the cache is freed and more pages are fed through.

  > So Marius asked a valid question and I'm curious myself how this issue
  > was dealt with by others. I suspect the answer is going to be something
  > like "a child process does the pipelining."

  The Bell + Howell has a batch-scanning mode which is used to implement
  the scan-ahead functionality. Once started, the scanner keeps scanning
  as fast as it can (based on the RSC cache availability, etc) until the
  feeder is out of documents, the stop button on the scanner is pressed
  or the host aborts/cancels batch mode.

  The normal non-batch mode would wait for the host to send the start
  scan command, and this would never result in the full rated throughput.

  On the SANE side, the sequence of calls to scan a feeder full of
  documents will look like this (... indicates multiple calls):

  [bh] sane_init called
  [bh] sane_open called
  [bh] sane_control_option called (option:0, action:0)...
  [bh] sane_get_option_descriptor called (option:0)...
  [bh] sane_start called
  [bh] sane_get_parameters called
  [bh] sane_read called...
  [bh] sane_start called
  [bh] sane_get_parameters called
  [bh] sane_read called...
  [bh] sane_start called
  [bh] sane_get_parameters called
  [bh] sane_read called...
  [bh] sane_start called
  [bh] sane_get_parameters called
  [bh] sane_read called...
  [bh] sane_start called
  [bh] sane_get_parameters called
  [bh] sane_read called...
  [bh] sane_start called
  [bh] sane_get_parameters called
  [bh] sane_read called...
  [bh] sane_start called (returns SANE_STATUS_NO_DOCS)
  [bh] sane_cancel called
  [bh] sane_close called
  [bh] sane_exit called

  It is important NOT to call sane_cancel until the entire batch is
  finished (sane_start returns SANE_STATUS_NO_DOCS). This gives the
  backend the understanding of the front-end's notion of "the batch".

  In the bh driver, I've not implemented the non-blocking io mode nor
  do I use a child process for buffering. The performance exhibited
  is close to the rated speed and the scanner seems to be swallowing
  pages as fast as it physically can.

  Tom Martone

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Henning Meier-Geinitz: "Re: preview and selectable scanarea for MFS-12000's ADF"
  - Previous message: Karsten Festag: "Re: microtek2 and scsi_read_image_status"
  - In reply to: Stephen Williams: "Re: Scan ahead"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Sat Mar 31 2001 - 08:32:47 PST