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

<!-- received="Sun Aug 15 20:34:27 1999 PDT" -->
<!-- sent="Sun, 15 Aug 1999 22:52:26 -0400" -->
<!-- name="Tom Martone" -->
<!-- email="tom@martoneconsulting.com" -->
<!-- subject="Re: SANE V2" -->
<!-- id="" -->
<!-- inreplyto="SANE V2" -->
<title>sane-devel: Re: SANE V2</title>
<h1>Re: SANE V2</h1>
<b>Tom Martone</b> (<a href="mailto:tom@martoneconsulting.com"><i>tom@martoneconsulting.com</i></a>)<br>
<i>Sun, 15 Aug 1999 22:52:26 -0400</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#189">[ date ]</a><a href="index.html#189">[ thread ]</a><a href="subject.html#189">[ subject ]</a><a href="author.html#189">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0190.html">Peter Aksberg: "SV: SV: modprobe"</a>
<li> <b>Previous message:</b> <a href="0188.html">Andreas Beck: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Andreas Beck wrote:<br>
<i>&gt; </i><br>
<i>&gt; The disadvantage I see is more a political, than a technical issue:</i><br>
<i>&gt; </i><br>
<i>&gt; If we allow any type to be transmitted, we as well to some extent encourage</i><br>
<i>&gt; "bad" backends to be written, that will only send "application/something_</i><br>
<i>&gt; weird" type data.</i><br>
<i>&gt; </i><br>
<i>&gt; This could be countered by requiring for a backend to be SANE compliant to</i><br>
<i>&gt; support at least one of the RAW datatypes. This as well ensures continuing</i><br>
<i>&gt; support for frontends, where saving to disk is not a good option, like</i><br>
<i>&gt; when operating xscanimage in GIMP mode.</i><br>
I agree with this requirement.  Luckily, in the Bell+Howell case, the<br>
scanner supports bit-depth 1, grayscale, so this is very easy to do.<br>
This is the default format that the backend will send; a --compression<br>
option (Values None, G4, G3-2D, G3-1D) controls the format of the data<br>
sent.  The default is None which sends _GRAY with bits_per_pixel = 1.<br>
If this option needs to be changed to a "well known" option, that is<br>
easily done as well.<br>
<p>
<i>&gt; I am fully with you, that SANE is intended for scanners, and should target</i><br>
<i>&gt; images, but if we can add other file types at no cost, Why not ?</i><br>
I'd just add that the G31D, G32D, and G42D need the getparm stuff.  These<br>
datastreams do not have the height and width encoded within them, but these<br>
are necessary to decoding.  You also need the resolution(s) which can be <br>
gotten by querying the option(s).  (It'd be nice to have the resolution(s)<br>
in the SANE_Parameter structure, but not at all necessary).<br>
<p>
The cost would seem to me to be the extra complexity in parsing through<br>
the mime stuff to get at the actual data stream.  And if I understand it<br>
properly, MIME doesn't provide a vehicle for specifying the height, width<br>
and resolution necessary to decode the image data.<br>
<p>
I think the MIME idea has merit *in addition* to the frame types that<br>
I proposed earlier.  When MIME will be used *instead*, then I'm unhappy.<br>
<p>
<i>&gt; To further simplify the process of writing front- or backends in a way that</i><br>
<i>&gt; allows to finally generate RAW data (in the sense, that the frontend can</i><br>
<i>&gt; make sense of the data) from common formats, I propose to have "middleends",</i><br>
<i>&gt; that can attach between a front and a backend (like the net stuff or the</i><br>
<i>&gt; dll backend does) and can convert from common filetypes to SANE RAW.</i><br>
This is a good idea and would be very helpful if you had a device that<br>
didn't luckily provide data in one of the basic SANE formats.<br>
<p>
<i>&gt; This allows to keep a backend driver simple, as if it is sending a data</i><br>
<i>&gt; type, for which a converting middleend exists, it doesn't need to worry</i><br>
<i>&gt; about internal conversion (which would mean code duplication in all backends</i><br>
<i>&gt; that happen to get a given kind of native input format from their HW).</i><br>
<i>&gt; </i><br>
<i>&gt; The other option to allow for full usage with compressed datatypes would be</i><br>
<i>&gt; implementing conversion in the frontends. This is also not good, as it means</i><br>
<i>&gt; code-duplication as well.</i><br>
<i>&gt; </i><br>
<i>&gt; So from the position of least code duplication, I think the middleends are a</i><br>
<i>&gt; good solution. It also gives tuneability for the parameters (jpeg-quality)</i><br>
<i>&gt; in a simple way, as a middleend can extend the optionlist.</i><br>
And in the high-volume area, you definitely want to avoid the middleend<br>
and send compressed data all the way through for performance reasons.<br>
So, you can choose not to use the middleend.  I like this.<br>
<p>
<i>&gt; &gt; If the scanner wants to speak text, it's probably beyond the territory</i><br>
<i>&gt; &gt; we should sensibly stake out for SANE. At that point you're looking at a</i><br>
<i>&gt; &gt; whole new class of device IMHO.</i><br>
<i>&gt; </i><br>
<i>&gt; No. If I got the guy with that high-speed scanning stuff right in his last</i><br>
<i>&gt; mail, he says, that those scanners can detect barcoded "batch separators".</i><br>
<i>&gt; Now if he makes a custom frontend, he will want to be able to detect those</i><br>
<i>&gt; and probably even make use of the data.</i><br>
<i>&gt; </i><br>
<i>&gt; I imagine his purpose is document archiving. Now he could just put a bunch</i><br>
<i>&gt; of pages in the scanner with such a separator page on top. The code on the</i><br>
<i>&gt; page would tell the frontend where to store/send the resulting files.</i><br>
<i>&gt; Now if we can convey that information "inline", this would allow to just</i><br>
<i>&gt; stack more pages with separators on top, and stuff gets sorted in</i><br>
<i>&gt; automatically.</i><br>
Yes, you got the idea very well.<br>
<p>
<i>&gt; &gt; application/sane?</i><br>
<i>&gt; </i><br>
<i>&gt; That the "proposed MIME-type" of the current data stream. It is using extra</i><br>
<i>&gt; outband data (width and height) from the getparms operation, which all</i><br>
<i>&gt; other formats we are talking of do not need, as they contain that inband.</i><br>
As I mentioned earlier the G31D, G32D, and G42D formats need outband data.<br>
I think the JFIF has it inband, and I'm not sure about the JBIG.<br>
<p>
<i>&gt; So I don't see much difference between our proposals, except for using</i><br>
<i>&gt; multiple frametypes vs. a single universal frametype.</i><br>
I think the multiple image frametypes are deserving of first class <br>
attention (e.g. their own frame types).  The MIME frametype has the <br>
advantage of extensibility, but seems to require more smarts in the <br>
frontend.  I could see dropping the _ASCII frame format and doing that<br>
through MIME.  I'd still prefer the _ASCII from a simplicity point of<br>
view, but I wouldn't fight for it.<br>
<p>
<i>&gt; For the frontend I do not see much difference between</i><br>
<i>&gt; </i><br>
<i>&gt; switch(parms.frametype) {</i><br>
<i>&gt;         case FT_JPG:...</i><br>
<i>&gt;         case FT_TIFFG3:...</i><br>
<i>&gt; }</i><br>
<i>&gt; </i><br>
<i>&gt; and</i><br>
<i>&gt; </i><br>
<i>&gt; if (strcmp(parms.mimetype,"image/jpeg")==0) {</i><br>
<i>&gt; ...</i><br>
<i>&gt; } else if (strcmp(parms.mimetype,"image/tiffg3")==0) {</i><br>
<i>&gt; ...</i><br>
<i>&gt; }</i><br>
How about:<br>
  switch(parms.frametype) {<br>
        case FT_JPG:...<br>
        case FT_TIFFG3:...<br>
        case FT_MIME:<br>
           if (strcmp(parms.mimetype,"image/jpeg")==0) {<br>
              ...<br>
           } else if (strcmp(parms.mimetype,"image/tiffg3")==0) {<br>
              ...<br>
           }<br>
  }<br>
<p>
This way a frontend, or middleend that wants to support the compressed<br>
image formats but avoid the MIME support can simply drop the third case.<br>
<p>
<i>&gt; 1. Add a well-known option that allows to select the transmission format.</i><br>
Fine, but you get into a bind when you have multiple transmissions in<br>
a single operation.  You get the G42D compressed data interspersed with<br>
the decoded barcodes, or simultaneous JFIF and TIFF from a single page,<br>
if I remember Stephen William's description correctly.  In the Bell+Howell<br>
backend the image transmission format is specified via the --compression<br>
option and the barcode stuff is specified through a series of options.<br>
And it is also possible to specify --compresion g42d and ask for a <br>
thumbnail (icon) also.  The thumbnails are uncompressed, but the full <br>
images are.<br>
<p>
<i>&gt; 2. Add a single bew frametype that announces the transmission of arbitrarily</i><br>
<i>&gt; formatted data. Add two identification fields somewhere that give the</i><br>
<i>&gt; mimetype and optionally a proposed filename for the data, so one can</i><br>
<i>&gt; correctly detect and handle the type of data. For "somewhere" I propose</i><br>
<i>&gt; either the file stream itself, like it is done in metamail, which is a</i><br>
<i>&gt; little awkward to handle in the frontend, or an extension to the parms</i><br>
<i>&gt; struct which is easier to handle, but a bit less compatible.</i><br>
I think the image formats proposed earlier (JFIF, G31D, G32D, G42D, and JBIG)<br>
need their own frame formats.  The MIME based one is quite extensible and<br>
can handle future growth.<br>
<p>
<i>&gt; 3. To simplify backend generation, middleends should be allowed that can</i><br>
<i>&gt; extend the available options for 1. by on-the-fly converting data from</i><br>
<i>&gt; backend format to others.</i><br>
I think this is a great idea, and is simplified by the image frame types.<br>
 <br>
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="0190.html">Peter Aksberg: "SV: SV: modprobe"</a>
<li> <b>Previous message:</b> <a href="0188.html">Andreas Beck: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>