kopia lustrzana https://gitlab.com/sane-project/website
231 wiersze
12 KiB
HTML
231 wiersze
12 KiB
HTML
<!-- received="Mon Aug 16 04:24:41 1999 PDT" -->
|
|
<!-- sent="Mon, 16 Aug 1999 13:23:51 +0200 (MET DST)" -->
|
|
<!-- name="becka@rz.uni-duesseldorf.de" -->
|
|
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
|
<!-- subject="Re: SANE V2" -->
|
|
<!-- id="199908161123.NAA11079@zeus.rz.uni-duesseldorf.de" -->
|
|
<!-- inreplyto="37B77CEA.C63CD9FC@martoneconsulting.com" -->
|
|
<title>sane-devel: Re: SANE V2</title>
|
|
<h1>Re: SANE V2</h1>
|
|
<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a><br>
|
|
<i>Mon, 16 Aug 1999 13:23:51 +0200 (MET DST)</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#194">[ date ]</a><a href="index.html#194">[ thread ]</a><a href="subject.html#194">[ subject ]</a><a href="author.html#194">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
|
|
<li> <b>Previous message:</b> <a href="0193.html">Ewald R. de Wit: "Re: SANE V2"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
|
|
<li> <b>Reply:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
Hi !<br>
|
|
<p>
|
|
<i>> I agree with this requirement. Luckily, in the Bell+Howell case, the</i><br>
|
|
<i>> scanner supports bit-depth 1, grayscale, so this is very easy to do.</i><br>
|
|
<i>> This is the default format that the backend will send; a --compression</i><br>
|
|
<i>> option (Values None, G4, G3-2D, G3-1D) controls the format of the data</i><br>
|
|
<i>> sent. The default is None which sends _GRAY with bits_per_pixel = 1.</i><br>
|
|
<i>> If this option needs to be changed to a "well known" option, that is</i><br>
|
|
<i>> easily done as well.</i><br>
|
|
<p>
|
|
O.K. - so you are with me with respect to letting the user or frontend choose <br>
|
|
compressed datatype by using a well-known option - right ?<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>> I'd just add that the G31D, G32D, and G42D need the getparm stuff. These</i><br>
|
|
<i>> datastreams do not have the height and width encoded within them, but these</i><br>
|
|
<i>> are necessary to decoding. You also need the resolution(s) which can be </i><br>
|
|
<i>> gotten by querying the option(s).</i><br>
|
|
<p>
|
|
I see. I also do not say, that the parameter struct shall always be empty <br>
|
|
or bogus, if we use the MIME transfer type.<br>
|
|
<p>
|
|
If a field makes sense, we should fill it out reasonably.<br>
|
|
<p>
|
|
<i>> (It'd be nice to have the resolution(s)</i><br>
|
|
<i>> in the SANE_Parameter structure, but not at all necessary).</i><br>
|
|
<p>
|
|
O.K. - I see the point in this. So it seems necessary to extend the params <br>
|
|
struct anyway - right ?<br>
|
|
<p>
|
|
If so, I suggest to add two short strings in there that allow to transfer<br>
|
|
a textual type description (MIME or better, if we have something better),<br>
|
|
and a suggested filename.<br>
|
|
Moreover additions that seem to be wanted are dpix/dpiy and probably a flag <br>
|
|
that separates pages instead of images, as some scanners can deliver multiple<br>
|
|
images per page.<br>
|
|
<p>
|
|
<i>> The cost would seem to me to be the extra complexity in parsing through</i><br>
|
|
<i>> the mime stuff to get at the actual data stream.</i><br>
|
|
<p>
|
|
Yes. And actuallz I should have phrased my proposal in another order.<br>
|
|
I as well think, that transferring the mimetype outband is better, as it is<br>
|
|
easier to do for both the front- and the backend, and we need less special <br>
|
|
casing to transfer the actual datastream.<br>
|
|
<p>
|
|
<i>> And if I understand it</i><br>
|
|
<i>> properly, MIME doesn't provide a vehicle for specifying the height, width</i><br>
|
|
<i>> and resolution necessary to decode the image data.</i><br>
|
|
<p>
|
|
It does. Mimetypes can have extra attributes. You could use <br>
|
|
"tiff/g3; height=452; width=7834; dpix= ...". However I agree with you, that<br>
|
|
this is not a good idea. WE should use fields in the params struct for it.<br>
|
|
they are already there, why waste them. <br>
|
|
<p>
|
|
<i>> I think the MIME idea has merit *in addition* to the frame types that</i><br>
|
|
<i>> I proposed earlier. When MIME will be used *instead*, then I'm unhappy.</i><br>
|
|
<p>
|
|
You are proposing something in between of 5-10 new frametypes. And <br>
|
|
frametypes are very indescriptive with respect to binary compatibility.<br>
|
|
<p>
|
|
You can convey any information you can put into a frametype in a string <br>
|
|
as well. And a string can be displayed to the user or looked up in a <br>
|
|
user-readable/writeable database to find something to do with the data.<br>
|
|
<p>
|
|
<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>
|
|
<i>> This is a good idea and would be very helpful if you had a device that</i><br>
|
|
<i>> didn't luckily provide data in one of the basic SANE formats.</i><br>
|
|
<p>
|
|
We could use that to simplify backend writing by writing middleends that<br>
|
|
by their existence allow to write backends that do not export the RAW <br>
|
|
datatypes.<br>
|
|
<p>
|
|
<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>
|
|
<i>> And in the high-volume area, you definitely want to avoid the middleend</i><br>
|
|
<i>> and send compressed data all the way through for performance reasons.</i><br>
|
|
<i>> So, you can choose not to use the middleend. I like this.</i><br>
|
|
<p>
|
|
Yes. I even thought it the other way round: You open the source, and when you <br>
|
|
find it doesn't transfer in a format you can handle, but you really<br>
|
|
want to handle the data instead of just saving them away, you re-open the<br>
|
|
source through the middleend, and will magically get a bunch of new formats,<br>
|
|
especially RAW.<br>
|
|
<p>
|
|
<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>
|
|
<p>
|
|
<i>> As I mentioned earlier the G31D, G32D, and G42D formats need outband data.</i><br>
|
|
<i>> I think the JFIF has it inband, and I'm not sure about the JBIG.</i><br>
|
|
<p>
|
|
O.K. - but this outband data is readily available from params - right ?<br>
|
|
<p>
|
|
<i>> I think the multiple image frametypes are deserving of first class </i><br>
|
|
<i>> attention (e.g. their own frame types). </i><br>
|
|
<p>
|
|
Note, that this is very bad for binary compatibility. If you get a backend <br>
|
|
that is newer than your frontend (not unusual, once manufacturer's start<br>
|
|
making backends), chances are, that you find it is willing to transmit in <br>
|
|
an unknown frametype. There is no reasonable way to find out, what this<br>
|
|
number means.<br>
|
|
<p>
|
|
A string gives the chance to ask the user.<br>
|
|
<p>
|
|
<i>> The MIME frametype has the advantage of extensibility, but seems to </i><br>
|
|
<i>> require more smarts in the frontend. </i><br>
|
|
<p>
|
|
Apart from replacing a switch() with a chain of if (strcmp()==) else if ...<br>
|
|
I see no difference.<br>
|
|
<p>
|
|
<i>> I could see dropping the _ASCII frame format and doing that through MIME.</i><br>
|
|
<i>> I'd still prefer the _ASCII from a simplicity point of view, but I </i><br>
|
|
<i>> wouldn't fight for it.</i><br>
|
|
<p>
|
|
I do not see a difference in complexity. <br>
|
|
<p>
|
|
<p>
|
|
<i>> switch(parms.frametype) {</i><br>
|
|
<i>> case FT_JPG:...</i><br>
|
|
<i>> case FT_TIFFG3:...</i><br>
|
|
<i>> case FT_MIME:</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>
|
|
<i>> }</i><br>
|
|
<p>
|
|
Why at all having the extra types, then ?<br>
|
|
<p>
|
|
The point is: If an application wants to handle a frametype, it needs to <br>
|
|
know it. If it knows the frametype, it as well knows the mimetype, as there<br>
|
|
is a 1:1 relation.<br>
|
|
<p>
|
|
<i>> This way a frontend, or middleend that wants to support the compressed</i><br>
|
|
<i>> image formats but avoid the MIME support can simply drop the third case.</i><br>
|
|
<p>
|
|
As the third case is a simple superset of the others, I see no gain. It's <br>
|
|
just a question of where the code gets written down. In your above scheme<br>
|
|
I would do:<br>
|
|
<p>
|
|
<i>> switch(parms.frametype) {</i><br>
|
|
<i>> case FT_JPG: jpg: ...</i><br>
|
|
<i>> case FT_TIFFG3: g3 : ...</i><br>
|
|
<i>> case FT_MIME:</i><br>
|
|
<i>> if (strcmp(parms.mimetype,"image/jpeg")==0) {</i><br>
|
|
<i>> goto jpg;</i><br>
|
|
<i>> } else if (strcmp(parms.mimetype,"image/tiffg3")==0) {</i><br>
|
|
<i>> goto g3;</i><br>
|
|
<i>> }</i><br>
|
|
<i>> }</i><br>
|
|
<p>
|
|
You see: no gain making a difference. It will be handled by the same code <br>
|
|
anyway.<br>
|
|
<p>
|
|
<i>> > 1. Add a well-known option that allows to select the transmission format.</i><br>
|
|
<i>> Fine, but you get into a bind when you have multiple transmissions in</i><br>
|
|
<i>> a single operation. You get the G42D compressed data interspersed with</i><br>
|
|
<i>> the decoded barcodes, or simultaneous JFIF and TIFF from a single page,</i><br>
|
|
<i>> if I remember Stephen William's description correctly. In the Bell+Howell</i><br>
|
|
<i>> backend the image transmission format is specified via the --compression</i><br>
|
|
<i>> option and the barcode stuff is specified through a series of options.</i><br>
|
|
<i>> And it is also possible to specify --compresion g42d and ask for a </i><br>
|
|
<i>> thumbnail (icon) also. The thumbnails are uncompressed, but the full </i><br>
|
|
<i>> images are.</i><br>
|
|
<p>
|
|
O.K. - this is a problem, but negotiating per frame would be a bit comple I <br>
|
|
think. IMHO the well known option should take care for the bulk "payload" <br>
|
|
data. If other chunks exist - o.k. The user can use his/her brain to use<br>
|
|
more detailed options.<br>
|
|
<p>
|
|
<i>> > 2. Add a single bew frametype that announces the transmission of arbitrarily</i><br>
|
|
<p>
|
|
<i>> I think the image formats proposed earlier (JFIF, G31D, G32D, G42D, and JBIG)</i><br>
|
|
<i>> need their own frame formats. The MIME based one is quite extensible and</i><br>
|
|
<i>> can handle future growth.</i><br>
|
|
<p>
|
|
O.K. - if it really really really pleases all people here, we can add that <br>
|
|
types. But as said, I am afraid of opening a neverending growth of the<br>
|
|
frame types, which is very bad regarding compatibility and cannot be easily <br>
|
|
extended by just editing a textfile or something.<br>
|
|
<p>
|
|
CU, ANdy<br>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Andreas Beck | Email : <<a href="mailto:Andreas.Beck@ggi-project.org">Andreas.Beck@ggi-project.org</a>>
|
|
<p>
|
|
<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="0195.html">Stephen Williams: "Re: SANE V2"</a>
|
|
<li> <b>Previous message:</b> <a href="0193.html">Ewald R. de Wit: "Re: SANE V2"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
|
|
<li> <b>Reply:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|