kopia lustrzana https://gitlab.com/sane-project/website
188 wiersze
10 KiB
HTML
188 wiersze
10 KiB
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>> </i><br>
|
||
<i>> The disadvantage I see is more a political, than a technical issue:</i><br>
|
||
<i>> </i><br>
|
||
<i>> If we allow any type to be transmitted, we as well to some extent encourage</i><br>
|
||
<i>> "bad" backends to be written, that will only send "application/something_</i><br>
|
||
<i>> weird" type data.</i><br>
|
||
<i>> </i><br>
|
||
<i>> This could be countered by requiring for a backend to be SANE compliant to</i><br>
|
||
<i>> support at least one of the RAW datatypes. This as well ensures continuing</i><br>
|
||
<i>> support for frontends, where saving to disk is not a good option, like</i><br>
|
||
<i>> 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>> I am fully with you, that SANE is intended for scanners, and should target</i><br>
|
||
<i>> 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>> To further simplify the process of writing front- or backends in a way that</i><br>
|
||
<i>> allows to finally generate RAW data (in the sense, that the frontend can</i><br>
|
||
<i>> make sense of the data) from common formats, I propose to have "middleends",</i><br>
|
||
<i>> that can attach between a front and a backend (like the net stuff or the</i><br>
|
||
<i>> 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>> This allows to keep a backend driver simple, as if it is sending a data</i><br>
|
||
<i>> type, for which a converting middleend exists, it doesn't need to worry</i><br>
|
||
<i>> about internal conversion (which would mean code duplication in all backends</i><br>
|
||
<i>> that happen to get a given kind of native input format from their HW).</i><br>
|
||
<i>> </i><br>
|
||
<i>> The other option to allow for full usage with compressed datatypes would be</i><br>
|
||
<i>> implementing conversion in the frontends. This is also not good, as it means</i><br>
|
||
<i>> code-duplication as well.</i><br>
|
||
<i>> </i><br>
|
||
<i>> So from the position of least code duplication, I think the middleends are a</i><br>
|
||
<i>> good solution. It also gives tuneability for the parameters (jpeg-quality)</i><br>
|
||
<i>> 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>> > If the scanner wants to speak text, it's probably beyond the territory</i><br>
|
||
<i>> > we should sensibly stake out for SANE. At that point you're looking at a</i><br>
|
||
<i>> > whole new class of device IMHO.</i><br>
|
||
<i>> </i><br>
|
||
<i>> No. If I got the guy with that high-speed scanning stuff right in his last</i><br>
|
||
<i>> mail, he says, that those scanners can detect barcoded "batch separators".</i><br>
|
||
<i>> Now if he makes a custom frontend, he will want to be able to detect those</i><br>
|
||
<i>> and probably even make use of the data.</i><br>
|
||
<i>> </i><br>
|
||
<i>> I imagine his purpose is document archiving. Now he could just put a bunch</i><br>
|
||
<i>> of pages in the scanner with such a separator page on top. The code on the</i><br>
|
||
<i>> page would tell the frontend where to store/send the resulting files.</i><br>
|
||
<i>> Now if we can convey that information "inline", this would allow to just</i><br>
|
||
<i>> stack more pages with separators on top, and stuff gets sorted in</i><br>
|
||
<i>> automatically.</i><br>
|
||
Yes, you got the idea very well.<br>
|
||
<p>
|
||
<i>> > application/sane?</i><br>
|
||
<i>> </i><br>
|
||
<i>> That the "proposed MIME-type" of the current data stream. It is using extra</i><br>
|
||
<i>> outband data (width and height) from the getparms operation, which all</i><br>
|
||
<i>> 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>> So I don't see much difference between our proposals, except for using</i><br>
|
||
<i>> 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>> For the frontend I do not see much difference between</i><br>
|
||
<i>> </i><br>
|
||
<i>> switch(parms.frametype) {</i><br>
|
||
<i>> case FT_JPG:...</i><br>
|
||
<i>> case FT_TIFFG3:...</i><br>
|
||
<i>> }</i><br>
|
||
<i>> </i><br>
|
||
<i>> and</i><br>
|
||
<i>> </i><br>
|
||
<i>> if (strcmp(parms.mimetype,"image/jpeg")==0) {</i><br>
|
||
<i>> ...</i><br>
|
||
<i>> } else if (strcmp(parms.mimetype,"image/tiffg3")==0) {</i><br>
|
||
<i>> ...</i><br>
|
||
<i>> }</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>> 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>> 2. Add a single bew frametype that announces the transmission of arbitrarily</i><br>
|
||
<i>> formatted data. Add two identification fields somewhere that give the</i><br>
|
||
<i>> mimetype and optionally a proposed filename for the data, so one can</i><br>
|
||
<i>> correctly detect and handle the type of data. For "somewhere" I propose</i><br>
|
||
<i>> either the file stream itself, like it is done in metamail, which is a</i><br>
|
||
<i>> little awkward to handle in the frontend, or an extension to the parms</i><br>
|
||
<i>> 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>> 3. To simplify backend generation, middleends should be allowed that can</i><br>
|
||
<i>> extend the available options for 1. by on-the-fly converting data from</i><br>
|
||
<i>> 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>
|