kopia lustrzana https://gitlab.com/sane-project/website
129 wiersze
6.7 KiB
HTML
129 wiersze
6.7 KiB
HTML
<!-- received="Mon Aug 30 20:05:50 1999 PDT" -->
|
||
<!-- sent="Mon, 30 Aug 1999 22:24:52 -0400" -->
|
||
<!-- name="Tom Martone" -->
|
||
<!-- email="tom@martoneconsulting.com" -->
|
||
<!-- subject="Re: SANE V2 - again..." -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="SANE V2 - again..." -->
|
||
<title>sane-devel: Re: SANE V2 - again...</title>
|
||
<h1>Re: SANE V2 - again...</h1>
|
||
<b>Tom Martone</b> (<a href="mailto:tom@martoneconsulting.com"><i>tom@martoneconsulting.com</i></a>)<br>
|
||
<i>Mon, 30 Aug 1999 22:24:52 -0400</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#360">[ date ]</a><a href="index.html#360">[ thread ]</a><a href="subject.html#360">[ subject ]</a><a href="author.html#360">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0361.html">Ewald R. de Wit: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0359.html">Adam Williams: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint LT"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0327.html">abel deuring: "SANE V2 - again..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
abel deuring wrote:<br>
|
||
<i>> </i><br>
|
||
<i>> Oliver Rauch wrote:</i><br>
|
||
<i>> ></i><br>
|
||
<i>> > Nick Lamb wrote:</i><br>
|
||
<i>> ></i><br>
|
||
<i>> > > Should all these data be</i><br>
|
||
<i>> > > > considered as one data stream by the backend / frontend API,</i><br>
|
||
<i>> > > > or should there be provisions to allow multiple data</i><br>
|
||
<i>> > > > streams? I am sure that Tom Martone and other people working</i><br>
|
||
<i>> > > > with this class of scanners have already thought about it,</i><br>
|
||
<i>> > > > so I would like hear comments from them.</i><br>
|
||
<i>> > ></i><br>
|
||
<i>> > > There is a provision for multiple data frames, so the question</i><br>
|
||
<i>> > > is: Should we use it for this in SANE 2.0, and I think the</i><br>
|
||
<i>> > > answer has to be "Yes", unless there's a better idea.</i><br>
|
||
<i>> > ></i><br>
|
||
<i>> > > (SANE 1.0 doesn't use multiple data frames for this purpose,</i><br>
|
||
<i>> > > but it does provide them for several other reasons anyway)</i><br>
|
||
<i>> > ></i><br>
|
||
<i>> ></i><br>
|
||
<i>> > Hm, can anyone tell me for what that shall be good?</i><br>
|
||
<i>> </i><br>
|
||
<i>> Hi Oliver,</i><br>
|
||
<i>> </i><br>
|
||
<i>> I simply wondered how Tom's backend/frontend combination handles the</i><br>
|
||
<i>> different types and sets of data (ASCII/pixel data) for one scan, and if</i><br>
|
||
<i>> there should be any kind of hints given by the backend to the frontend,</i><br>
|
||
<i>> how to handle these sets of data: should they be stored just in one</i><br>
|
||
<i>> file, or in several files, for example.</i><br>
|
||
The backend/frontend combination handles the different types of data<br>
|
||
by lying about it, basically. Both the compressed image data (ccitt-g4)<br>
|
||
and the text decoded barcode information are sent in a SANE_FRAME_GRAY<br>
|
||
frame. But the frontend has a --raw commandline option which disables<br>
|
||
the writing of the pbm header to the file, so you just get the raw <br>
|
||
data written out.<br>
|
||
<p>
|
||
I'd rather be able to tell the truth, so to speak, and give a proper<br>
|
||
hint as to the format of the frame. Then each frontend could choose<br>
|
||
to do with it what it thought was best, but that the baseline <br>
|
||
functionality would be to pass it uninterpreted onwards like the<br>
|
||
behavior I get with the --raw commandline option. <br>
|
||
<p>
|
||
The frontend, scanadf, allows you to specify a scan script which gets <br>
|
||
forked off for each image aquired and this allows the user/integrator<br>
|
||
great flexibility in doing stuff with each captured file. It provides<br>
|
||
a nice separation between the basic frontend and the specifics of<br>
|
||
a particular application's requirements. What I typically do with <br>
|
||
the g4 data is to convert it to a full-fledged tiff file using a <br>
|
||
simple utility called g42tiff, which is a slightly modified<br>
|
||
version of fax2tiff from the tools within Sam Leffler's libtiff code.<br>
|
||
Our imaging archive system uses tiff as its file format of choice.<br>
|
||
You could also scan without compression, getting true _GRAY data<br>
|
||
and have the scan script use pnmtotiff to get the same result. It <br>
|
||
just seems nice to have the data compressed in the firmware of the<br>
|
||
scanner and have a much smaller amount of data flow across the SCSI<br>
|
||
<p>
|
||
bus and through the software. Any savings here would be more noticeable<br>
|
||
if you were going through saned/net as well.<br>
|
||
<p>
|
||
Now getting at the barcode data is a different matter. Basically the<br>
|
||
encoded data is to be associated with the image in the "document<br>
|
||
database" which provides the infrastructure to support flexible<br>
|
||
searches for retrieval. In one case, the encoded data is an employee<br>
|
||
identifier - the employee who signed and returned the document. This <br>
|
||
allows the document (image) to be associated with that person in a<br>
|
||
relational database. Then it is a trivial matter to collect all the<br>
|
||
documents for a person, etc. The barcoding technique helps to eliminate<br>
|
||
a manual data entry process and is quite desireable in terms of labor<br>
|
||
savings.<br>
|
||
<p>
|
||
So for barcodes the scan script pulls out the decoded data and stores<br>
|
||
it in a index file which is used to update the database. All this<br>
|
||
happens during the scan process which streamlines things and allows<br>
|
||
for good throughput.<br>
|
||
<p>
|
||
Now there might be more sophisticated ways of associating a series<br>
|
||
of data streams (frames) together as being from the same page, but<br>
|
||
I don't really see a dire need for this. As long as the frames <br>
|
||
arrive in a well-defined (by the backend), predictable manner,<br>
|
||
a custom scan script should be able to make the association simply<br>
|
||
by the sequence. The front end really doesn't know about this at<br>
|
||
all, and that's all right, the job gets done.<br>
|
||
<p>
|
||
I hope this is the information you were seeking. I'm not quite sure<br>
|
||
I understood you completely regarding the multiple data frames, so I<br>
|
||
may have missed something here.<br>
|
||
<p>
|
||
<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="0361.html">Ewald R. de Wit: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0359.html">Adam Williams: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint LT"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0327.html">abel deuring: "SANE V2 - again..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|