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

<!-- received="Tue Aug  3 20:24:39 1999 PDT" -->
<!-- sent="Tue, 03 Aug 1999 22:43:48 -0400" -->
<!-- name="Tom Martone" -->
<!-- email="tom@martoneconsulting.com" -->
<!-- subject="Re: SANE_FRAME Formats (was Re: xsane-0.31 available)" -->
<!-- id="" -->
<!-- inreplyto="SANE_FRAME Formats (was Re: xsane-0.31 available)" -->
<title>sane-devel: Re: SANE_FRAME Formats (was Re: xsane-0.31 available)</title>
<h1>Re: SANE_FRAME Formats (was Re: xsane-0.31 available)</h1>
<b>Tom Martone</b> (<a href="mailto:tom@martoneconsulting.com"><i>tom@martoneconsulting.com</i></a>)<br>
<i>Tue, 03 Aug 1999 22:43:48 -0400</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#40">[ date ]</a><a href="index.html#40">[ thread ]</a><a href="subject.html#40">[ subject ]</a><a href="author.html#40">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0041.html">Steve Gunnell: "Re: RGBI (was Re: xsane-0.31 available)"</a>
<li> <b>Previous message:</b> <a href="0039.html">Allan Strand: "Re: Sane + FreeBSD 3.2"</a>
<li> <b>Maybe in reply to:</b> <a href="0019.html">Andreas Rick: "SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0047.html">Steve Gunnell: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Oliver Rauch wrote:<br>
<i>&gt; </i><br>
<i>&gt; Stephen Williams wrote:</i><br>
<i>&gt; </i><br>
<i>&gt; &gt; If all applications must support any combination of frame types, then</i><br>
<i>&gt; &gt; the application writers will go nuts. If, on the other hand the scanner</i><br>
<i>&gt; &gt; vendors must work with an excessively short list of formats, they will</i><br>
<i>&gt; &gt; not be able to demonstrate the value of their nifty expensive equipment.</i><br>
<i>&gt; </i><br>
<i>&gt; I think we must find a good way between that.</i><br>
<i>&gt; If a frontend is not able to handle a special file format: ok - no problem</i><br>
<i>&gt; We should add formats that will be used by different backends.</i><br>
<i>&gt; That will e.g. be some formats for still cameras.</i><br>
<i>&gt; </i><br>
<i>&gt; If there is one backend that uses a prorietary format it has to convert</i><br>
<i>&gt; it into another format or it has to pass it trough in raw format.</i><br>
Greetings,<br>
<p>
Document scanners such as the Bell+Howell scanners can produce CCITT-G3,<br>
CCITT-G3-2D, and CCITT-G4 compressed image streams.  I'm not sure if it<br>
would be appropriate to classify these formats as proprietary although<br>
they are certainly not specifically supported by SANE.  <br>
<p>
What I've done in the Bell+Howell backend when the user chooses a <br>
compressed format is to lie and state that the frame type is _GREY <br>
and to use a modified scanimage that has a --raw option that when <br>
use avoids writing the PBM header, thereby writing the raw data to a file.<br>
When the user chooses an uncompressed format, _GREY is used and all<br>
frontends will be happy.  <br>
<p>
Then to process that raw file (e.g. to convert the raw G4 data to a <br>
TIFF file) you need the resolution, height, and width of the scanned <br>
image.  Height and Width are gotten from the parameter block and <br>
the resolution value(s) is gotten from the option setting(s).  <br>
For each image scanned a user supplied script is invoked which receives <br>
the datafile as an argument and the resolution, height, and width as <br>
environment variables.  Armed with this information, the script can <br>
process the compressed data as it pleases.<br>
<p>
It seems that a _RAW frame format would be helpful, so that I need not<br>
lie and say that it is _GREY and then --raw option would not be<br>
needed as the appropriate behavior for dealing with _RAW frames would<br>
be to pass them unmodified to a file.  I think adding _G3, _G32D, and _G4<br>
frame formats would be unnecessary, even though I'm pretty sure that<br>
there are other document scanners that support these compressed formats.<br>
<p>
And then to get *really* strange, this scanner is capable of decoding<br>
barcodes.  So you want to get the decoded barcode data back from the<br>
scanner through SANE.  That's where you *really* have to lie, because <br>
this is not image data at all.  What I've done in this case is to write<br>
the barcode data into an XML format and send it back as "raw".  So, I<br>
think it's important to have the _RAW (don't touch me) format as I'm<br>
sure that adding an _XML or _TEXT frame format will be objected to<br>
for one reason or another and I would be inclined agree with the <br>
objection myself.<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="0041.html">Steve Gunnell: "Re: RGBI (was Re: xsane-0.31 available)"</a>
<li> <b>Previous message:</b> <a href="0039.html">Allan Strand: "Re: Sane + FreeBSD 3.2"</a>
<li> <b>Maybe in reply to:</b> <a href="0019.html">Andreas Rick: "SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0047.html">Steve Gunnell: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- reply="end" -->
</ul>