sane-project-website/old-archive/1999-08/0176.html

<!-- received="Sun Aug 15 13:12:48 1999 PDT" -->
<!-- sent="Sun, 15 Aug 1999 15:29:36 -0400" -->
<!-- name="Tom Martone" -->
<!-- email="tom@martoneconsulting.com" -->
<!-- subject="Re: SANE frames" -->
<!-- id="" -->
<!-- inreplyto="SANE frames" -->
<title>sane-devel: Re: SANE frames</title>
<h1>Re: SANE frames</h1>
<b>Tom Martone</b> (<a href="mailto:tom@martoneconsulting.com"><i>tom@martoneconsulting.com</i></a>)<br>
<i>Sun, 15 Aug 1999 15:29:36 -0400</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#176">[ date ]</a><a href="index.html#176">[ thread ]</a><a href="subject.html#176">[ subject ]</a><a href="author.html#176">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0177.html">Nick Lamb: "Re: SANE V2"</a>
<li> <b>Previous message:</b> <a href="0175.html">Andreas Beck: "Re: SG_BIG_BUFF, glibc 2.1 weirdness ..."</a>
<li> <b>Maybe in reply to:</b> <a href="0173.html">Stephen Williams: "SANE frames"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0178.html">Tom Martone: "Re: SANE frames"</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Stephen Williams wrote:<br>
<i>&gt; </i><br>
<i>&gt; <a href="mailto:oliver.rauch@Wolfsburg.DE">oliver.rauch@Wolfsburg.DE</a> said:</i><br>
<i>&gt; &gt; May be we should add a generic n-channel frame format</i><br>
<i>&gt; &gt; (SANE_FRAME_N_CHANNELS or dthg like that) and put the numbers of</i><br>
<i>&gt; &gt; frames and a list with the name/types of the frames into the parameter</i><br>
<i>&gt; &gt; block.</i><br>
<i>&gt; </i><br>
<i>&gt; This reminds me. Some of the scanners I'm working on not only generate</i><br>
<i>&gt; compressed images, but can have multiple images per page. I'm thinking</i><br>
<i>&gt; for example of one document scanner that can, for each page, produce</i><br>
<i>&gt; all at once:</i><br>
<i>&gt; </i><br>
<i>&gt;         up to 8 color images</i><br>
<i>&gt;         up to 8 gray images</i><br>
<i>&gt;         up to 8 binary images</i><br>
<i>&gt; </i><br>
<i>&gt; Not to mention backside images as well. Each image can have different</i><br>
<i>&gt; characteristics (i.e. JFIF color/gray, TIFF G4 binary) and dimensions.</i><br>
<i>&gt; In particular, the scanner supports windows with these different properties</i><br>
<i>&gt; and their own scan area. An aware application needs to be able to find</i><br>
<i>&gt; out that these images are from the same page. Ideas?</i><br>
Perhaps the backend could set an option value (SANE_CAP_SOFT_DETECT)<br>
that specifies the number of images per scan operation?  In my usage,<br>
since it is batch aquisition, I rely on an external process to "paginate"<br>
the images.  The user is actually knowledgeable about how many images<br>
per pages scanned will be delivered, because they are specifying the<br>
options (duplex, multiple sections, etc)  This is limiting, though.<br>
<p>
Another thing that's pretty typical is using batchcode or patchcodes <br>
to separate multiple page documents.  I've not really gotten to far <br>
into that issue, however.  Again, I was thinking that an external <br>
process would handle that one as well, as long as I could get the <br>
decoded bar/patchcode data through SANE.<br>
<p>
But just getting the multiple images per physical scan operation through<br>
SANE is an issue as well.  Just like in your scanner example, Bell+Howell<br>
supports 8 scanning windows as well as the full scan area and a user-<br>
sizeable thumbnail (or icon).  Duplex models support this on both sides<br>
of the pages, so you can get up to 20 images for each page that goes<br>
through the scanner.<br>
<p>
1 Full Front Page<br>
1 Front Page Thumbnail (Icon)<br>
8 User-Defined Front Page Sections (scan areas)<br>
1 Full Back Page<br>
1 Back Page Thumbnail (Icon)<br>
8 User-Defined Back Page Sections (scan areas)<br>
<p>
The thumbnails cannot be compressed, but the other images can be.  They<br>
must all use the same compression setting however, if I remember correctly.<br>
<p>
Then if you add in the barcode/patchcode feature you get an additional<br>
18 more items per side, potentially.  But I was thinking of consolidating<br>
all of that into a single xml-encoded text stream.  Any ideas on this one?<br>
<p>
The multiple images per physical scan operation can be handled by<br>
a judicious calling of sane_cancel by the frontend.  This gives the <br>
backend a clue as to whether to return subsequent images from the latest<br>
physical scan operation, or to drop them and actually scan the next page.<br>
<p>
I posted a message regarding my method for supporting this a while back.<br>
I'll repeat it here.  If you look at Section 4.4 Code Flow there's a <br>
diagram which shows the sequence of calls that a front-end should make<br>
and a paragraph which specifically mentions when sane_cancel must be <br>
called.  Here it is:<br>
<p>
  Image data is collected by repeatedly calling sane_read(). Eventually, <br>
  this function will return an end-of-file status (SANE_STATUS_EOF). <br>
  This indicates the end of the current frame. If the frontend expects<br>
  additional frames (e.g., the individual channels in of a red/green/blue <br>
  image or multiple images), it can call sane_start() again. Once all <br>
  desired frames have been acquired, function sane_cancel() must be <br>
  called. This operation can also be called at any other time to cancel <br>
  a pending operation. Note that sane_cancel() must be called even if <br>
  the last read operation returned SANE_STATUS_EOF. <br>
<p>
Now here are traces of scanadf and xsane 0.31 calling the Bell+Howell <br>
backend with the feeder loaded with 3 pages and a duplex scan requested.<br>
The goal of course is to acquire 6 images: 3 fronts and 3 backs.<br>
<p>
<i>&gt;From scanadf.adf.duplex.log</i><br>
<p>
[bh] sane_init called<br>
   [bh] sane_open called<br>
      [bh] sane_control_option called (option:0, action:0)...<br>
      [bh] sane_get_option_descriptor called (option:0)...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_read called...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_read called...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_read called...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_read called...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_read called...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_read called...<br>
      [bh] sane_start called (returns SANE_STATUS_NO_DOCS)<br>
      [bh] sane_cancel called<br>
   [bh] sane_close called<br>
[bh] sane_exit called<br>
<p>
<i>&gt;From xsane.adf.duplex.log</i><br>
<p>
[bh] sane_init called<br>
   [bh] sane_get_devices called<br>
   [bh] sane_open called<br>
      [bh] sane_control_option called (option:0, action:0)...<br>
      [bh] sane_get_option_descriptor called (option:1)...<br>
*     [bh] sane_get_parameters called<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_set_io_mode called: non_blocking=1<br>
         [bh] sane_read called...<br>
         [bh] sane_get_option_descriptor called...<br>
      [bh] sane_cancel called<br>
*     [bh] sane_get_parameters called<br>
      [bh] sane_get_option_descriptor called (option:0)...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_set_io_mode called: non_blocking=1<br>
         [bh] sane_read called...<br>
         [bh] sane_get_option_descriptor called (option:0)...<br>
      [bh] sane_cancel called<br>
*     [bh] sane_get_parameters called<br>
      [bh] sane_get_option_descriptor called (option:0)...<br>
      [bh] sane_start called<br>
         [bh] sane_get_parameters called<br>
         [bh] sane_set_io_mode called: non_blocking=1<br>
         [bh] sane_read called...<br>
         [bh] sane_get_option_descriptor called (option:0)...<br>
      [bh] sane_cancel called<br>
*     [bh] sane_get_parameters called<br>
      [bh] sane_get_option_descriptor called (option:0)...<br>
      [bh] sane_start called<br>
         [bh] sane_get_option_descriptor called (option:0)...<br>
   [bh] sane_close called<br>
[bh] sane_exit called<br>
 <br>
The resulting behavior is that scanadf gets 6 images and xsane gets<br>
3 images.  The reason is that each frontend has a different idea on<br>
when sane_cancel must be called.  Oliver tells me that the scanadf<br>
behavior is not conforming to the standard; I don't share that view<br>
and would welcome others to comment.  <br>
<p>
Assuming for a moment that scanadf is indeed proper, then the aquisition<br>
of each and every image produced by the Bell+Howell per physical page<br>
can be passed through to the front end, exactly as in this duplex<br>
scenario.  So on this issue, I think we're very close to having a<br>
officially sanctioned standard solution.  Perhaps, this could be added<br>
to the paragraph above to alert frontend writers to the subtleties of<br>
the sane_cancel call.<br>
<p>
   If a frontend is performing a multiple image aquisition operation<br>
   (e.g., acquiring images from a duplex scanner, or a scanner with<br>
   section support, acquiring images from a scanner equipped with an<br>
   automatic document feeder), the frontend should call sane_cancel once <br>
   only after all images have been acquired.  This allows a backend a hint<br>
   as to the duration of the batch and provides an opportunity for the<br>
   backend to perform batch related optimizations or deliver multiple<br>
   images from a single physical scan operation.<br>
<p>
Related to the above is the special "batch mode" supported by the <br>
Bell+Howell.  In this mode the scanner is actually ahead of the host<br>
in terms of feeding in paper and scanning.  It buffers the image data<br>
in its own memory and the hardware compression and barcode decoding<br>
are taking place simultaneously with the scanning of the subsequent<br>
image.  The Bell+Howell backend, when the batch option is turned on,<br>
starts batch mode prior to the first START SCAN and terminates the<br>
batch mode when sane_cancel is called.  This works real nice.<br>
<p>
<i>&gt; </i><br>
<i>&gt; This is not so pressing to me as the application being able to select</i><br>
<i>&gt; compressed frame formats (and blocking formats it can't handle) but</i><br>
<i>&gt; someone should be thinking of these things.</i><br>
<i>&gt; </i><br>
<i>&gt; I know, I'm a pest on this list:-)</i><br>
I don't think you are a pest.  Rather, it seems that a lot of the focus<br>
is on interactive, high-depth color scanning, while some of us are working<br>
in a quite different niche, that of high-volume, low-resolution, bilevel<br>
or grayscale scanning.  In this arena, there are different problems to<br>
solve.  I'm glad you're active in this area; it gives me the confidence<br>
that we can work together and make a bunch of progress in this area.<br>
<p>
It think we share the following issues:<br>
1) image compression, which involves adding SANE frame formats.<br>
2) duplex scanning/multiple scan windows<br>
3) feeder support/batch operation/performance issues<br>
4) barcode/patchcode support, perhaps also tied to SANE frame formats,<br>
   but even stranger because the data is not an image at all.<br>
<p>
If I missed some, please add them.<br>
<p>
I think all of these are addressable without a great deal of alteration<br>
to the SANE standard.  In fact, I have a workable solution for my needs<br>
at the moment.  I'd really like to integrate this all back in and get<br>
blessing, etc.  I'd also like to be able to use some of the esoteric<br>
functions of the Bell+Howell backend with Xsane.  Oliver recently added<br>
ADF support to version 0.31 of Xsane which works fine with the Bell+<br>
Howell, but the multiple images per physical scan issue not being supported<br>
reduces its usefulness.  Currently, each of the 4 options above do not <br>
work with arbitrary frontends.  I see that as a necessary hurdle to jump <br>
over, and incorporating these features into the standard is the right <br>
way to go.  <br>
<p>
To that end, I'm preparing to address issues 1 and 4 in a following email.<br>
<p>
I think number 2 is pretty well outlined by both of us here, and hopefully <br>
we'll get some feedback regarding the conformance concerns.  <br>
<p>
I think number 3 boils down to either a totally new frontend for high <br>
volume document scanning, or significant enhancements to scanimage.<br>
<p>
Tom Martone<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="0177.html">Nick Lamb: "Re: SANE V2"</a>
<li> <b>Previous message:</b> <a href="0175.html">Andreas Beck: "Re: SG_BIG_BUFF, glibc 2.1 weirdness ..."</a>
<li> <b>Maybe in reply to:</b> <a href="0173.html">Stephen Williams: "SANE frames"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0178.html">Tom Martone: "Re: SANE frames"</a>
<!-- reply="end" -->
</ul>