kopia lustrzana https://gitlab.com/sane-project/website
263 wiersze
13 KiB
HTML
263 wiersze
13 KiB
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>> </i><br>
|
||
<i>> <a href="mailto:oliver.rauch@Wolfsburg.DE">oliver.rauch@Wolfsburg.DE</a> said:</i><br>
|
||
<i>> > May be we should add a generic n-channel frame format</i><br>
|
||
<i>> > (SANE_FRAME_N_CHANNELS or dthg like that) and put the numbers of</i><br>
|
||
<i>> > frames and a list with the name/types of the frames into the parameter</i><br>
|
||
<i>> > block.</i><br>
|
||
<i>> </i><br>
|
||
<i>> This reminds me. Some of the scanners I'm working on not only generate</i><br>
|
||
<i>> compressed images, but can have multiple images per page. I'm thinking</i><br>
|
||
<i>> for example of one document scanner that can, for each page, produce</i><br>
|
||
<i>> all at once:</i><br>
|
||
<i>> </i><br>
|
||
<i>> up to 8 color images</i><br>
|
||
<i>> up to 8 gray images</i><br>
|
||
<i>> up to 8 binary images</i><br>
|
||
<i>> </i><br>
|
||
<i>> Not to mention backside images as well. Each image can have different</i><br>
|
||
<i>> characteristics (i.e. JFIF color/gray, TIFF G4 binary) and dimensions.</i><br>
|
||
<i>> In particular, the scanner supports windows with these different properties</i><br>
|
||
<i>> and their own scan area. An aware application needs to be able to find</i><br>
|
||
<i>> 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>>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>>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>> </i><br>
|
||
<i>> This is not so pressing to me as the application being able to select</i><br>
|
||
<i>> compressed frame formats (and blocking formats it can't handle) but</i><br>
|
||
<i>> someone should be thinking of these things.</i><br>
|
||
<i>> </i><br>
|
||
<i>> 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>
|