Tom,
Thanks muchly for this.
I'm still unclear on how a f/e knows that there is new image, and not
just a new frame for the current image. Is it implied by what frames
have been recieved.
So if we looked at just the getparameter replies is the following how it
is intended to work:
GetParameters (format=Red, LastFrame=false)
GetParameters (format=Green, LastFrame=false)
GetParameters (format=Blue, LastFrame=false)
// Implies a new image cause we've already read r, g & b
GetParameters (format=Grey, LastFrame=false)
// Implies a new image cause we've read grey image which only has simple
frame
GetParameters (format=RGB, LastFrame=false)
// Implies a new image cause we've read rgb image which only has simple
frame
...
mick
Tom Martone wrote:
>
> Greetings,
>
> Mick Barry wrote:
> >
> > Would it be possible to back up just a little and explain how scanning
> > multiple pages (currently) appears to a f/e?
> >
>
> I searched through some of the archives and found these two messages
> that pretty well describes the issues around multiple pages, batches,
> adfs and duplexes...
>
> The other way to understand more completely would be to examine, xsane,
> scanadf, and the bh and umax backends.
>
> (I would have put links to these, but the search server is down now
> and I don't know how else to do this other than insert it below)
>
> Tom Martone
>
> >--------------------------------------------------------------
> >Date: Mon, 09 Aug 1999 21:42:50 -0400
> >From: Tom Martone <tom@martoneconsulting.com>
> >To: sane mailing list <sane-devel@mostang.com>
> >Subject: Interpretation of the Standard
> >
> >Greetings,
> >
> >I'm working on a backend for Bell+Howell document scanners and a
> >command line frontend suitable for batch scanning. These scanners
> >are typically equipped with automatic document feeders and are not
> >flatbed scanners. Some models are capable of duplex scanning. These
> >have dual cameras which capture both sides of the paper as the paper
> >travels through the scanner.
> >
> >In a scenario where 3 pages are loaded into the feeder, a "scan all
> >pages in the feeder" operation is requested in duplex mode, one would
> >expect to produce 6 images (3 fronts and 3 backs). The following
> >sequence of calls are made. Elipses indicate many such calls and
> >in the case of sane_read, the last call returns SANE_STATUS_EOF.
> >
> >[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
> >
> >I'd be interested in knowing whether you think that the call sequence
> >above is following the standard, specifically the portion I've quoted
> >below, from section 4.4 Code Flow.
> >
> > "Image data is collected by repeatedly calling sane_read().
> > Eventually, this function will return an end-of-file status
> > (SANE_STATUS_EOF). This indicates the end of the current frame.
> > If the frontend expects additional frames (e.g., the individual channels
> > in of a red/green/blue image or multiple images), it can call sane_start()
> > again. Once all desired frames have been acquired, function sane_cancel()
> > must be called. This operation can also be called at any other time to
> > cancel a pending operation. Note that sane_cancel() must be called
> > even if the last read operation returned SANE_STATUS_EOF."
> >
> >I'd argue that a batch scanning front-end is expecting additional
> >frames when it is attempting to empty the feeder and it need not
> >call sane_cancel until it has detected an empty feeder (sane_start
> >returning SANE_STATUS_NO_DOCS). In fact, I'd say that this judicious
> >calling of sane_cancel is the only way that a front-end can "hint"
> >to a back-end the duration of a "batch". This is important
> >if one wants to take advantage of a high-performance batch mode that
> >the Bell+Howell implements. In this mode, the scanner is free to
> >be ahead of the host during a scan operation, buffering image data
> >in its own memory. This batch mode needs to be started (I do it in
> >the first start_scan call) and then aborted (I do it in the sane_cancel
> >call).
> >
> >If you are thinking that the code flow above is NOT following the
> >standard, then consider the following:
> >
> >In duplex mode, the backend delivers the front image for first sane_start
> >and the back image for the next sane_start. Up until this point only a
> >single "real" START SCAN has been sent to the scanner, but there are
> >two images available for the backend to read and transmit to the frontend.
> >
> >Also, if the frontend calls sane_cancel each time after sane_read returned
> >SANE_STATUS_EOF, there would be no way for the backend to know whether
> >the user wants the behavior above (normal) or whether they cancelled
> >the operation after the first front page and have started a new scan
> >(in which case scanning the front page of the next document would
> >be the correct action for the backend).
> >
> >Thanks,
> >Tom Martone
>
> >--------------------------------------------------------------
> >Date: Tue, 17 Aug 1999 09:18:46 -0700
> >From: David Mosberger-Tang <David.Mosberger@acm.org>
> >To: sane-devel@mostang.com
> >Subject: Re: SANE frames
> >
> >>>>>> On Mon, 16 Aug 1999 17:42:47 +0200, Oliver Rauch <oliver.rauch@Wolfsburg.DE> said:
> >
> > Oliver> the sane standard defines of how much frames an image
> > Oliver> consists. After the last frame - that means if the image is
> > Oliver> transferred completly - the frontend has to call
> > Oliver> sane_cancel.
> >
> >Actually, IIRC, our intent was indeed to allow the call sequence that
> >Tom describes. Note that in 4.4 it says:
> >
> > "If the frontend expects additional frames (e.g., the individual channels
> > in of a red/green/blue image or multiple images), it can call sane_start()
> > ^^^^^^^^^^^^^^^^^^
> > again."
> >
> >Also, note that xcam does acquire multiple images without calling
> >sane_cancel(). (It's an amusing exercise to test a scanner with xcam,
> >actually ;-)
> >
> >In other words, the idea is to have sane_start() be called, and
> >collect as many images as the frontend wants (which could in turn
> >consist of multiple frames each as indicated by frame-type) and when
> >the frontend is done, it should call sane_cancel(). Sometimes it's
> >better to think of sane_cancel() as "sane_stop()" but that name would
> >have had some misleading connotations as well, that's why we stuck
> >with "cancel".
> >
> > --david
>
> --
> Source code, list archive, and docs: http://www.mostang.com/sane/
> To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Thu Mar 01 2001 - 00:47:20 PST