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

<!-- received="Sat Aug 14 17:14:49 1999 PDT" -->
<!-- sent="Sun, 15 Aug 1999 02:17:31 +0200 (MEST)" -->
<!-- name="becka@rz.uni-duesseldorf.de" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="SANE V2 - past discussions. A summary." -->
<!-- id="m11FnzQ-000CDTC@hades.beck-sw.de" -->
<!-- inreplyto="199908141750.KAA02998@icarus.com" -->
<title>sane-devel: SANE V2 - past discussions. A summary.</title>
<h1>SANE V2 - past discussions. A summary.</h1>
<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a><br>
<i>Sun, 15 Aug 1999 02:17:31 +0200 (MEST)</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#151">[ date ]</a><a href="index.html#151">[ thread ]</a><a href="subject.html#151">[ subject ]</a><a href="author.html#151">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0152.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>Previous message:</b> <a href="0150.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>In reply to:</b> <a href="0147.html">Stephen Williams: "Re: [Fwd: Re: Discussion about SANE and TWAIN...]"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
<li> <b>Reply:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
<li> <b>Reply:</b> <a href="0165.html">Oliver Rauch: "Re: SANE V2 - past discussions. A summary."</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Hi !<br>
<p>
<i>&gt; a SANE driver for. However, I need some more complete frame types as</i><br>
<i>&gt; this scanner produces JFIF and TIFF/G4 images (simultaneously) and I</i><br>
<i>&gt; would *like* to just pass the JFIF data as a coded SANE frame.</i><br>
<i>&gt; Once I do that, I'll have access to some high-speed document scanners</i><br>
<i>&gt; that I would also like to write drivers for.</i><br>
<i>&gt; Is there a place where I can see a draft of what SANE 2.x will contain,</i><br>
<i>&gt; so that I (we) can comment?</i><br>
<p>
O.K. - I will forward all mails I and David exchanged on that topic.<br>
Maybe I'll add some rant at the end as well, reviewing them from a<br>
greater distance.<br>
Such rant will be marked with ###.<br>
<p>
Here you are:<br>
<p>
------------ snip --------------<br>
<p>
O.k. - as the recent interest in doing compressed file transmission and<br>
a TWAIN bridge show demand for that, I have written up a little summary on<br>
what has been thought of as new features SANE 2.0<br>
<p>
<p>
A. From the SANE docs: LEVEL2:<br>
------------------------------<br>
<p>
** Tue Jun  3 10:22:33 1997<br>
<p>
Here are some ideas under discussion for the next major revision of<br>
the SANE API:<br>
<p>
 o Additional image data types, such as JPEG, MPEG, FlashPix, raw.<br>
   These would be useful for devices that directly generate such<br>
   formats (still cameras, for example).  The raw image format could<br>
   be used when no other format is applicable.  This would allow to<br>
   at least read and save the data in a file.  This would probably<br>
   have to be coupled with adding a function that lets a frontend<br>
   tell the backend what level it supports, something like<br>
   sane_set_level (int max_supported_level).<br>
   [Based on suggestion by Andreas Beck &lt;<a href="mailto:becka@ggi-project.org">becka@ggi-project.org</a>&gt;]<br>
<p>
 o Support for other multimedia types, such as audio.  This probably<br>
   would also require adding a write() interface to the SANE API.<br>
   [Suggested by Erik Troan &lt;<a href="mailto:ewt@redhat.com">ewt@redhat.com</a>&gt;.]<br>
<p>
B. From some private communications I found in my backlog:<br>
----------------------------------------------------------<br>
<p>
** Tue Oct 20 22:02:03 1998: Andy:<br>
<p>
<i>&gt;       - when will there be JPEG support in the SANE interface? i guess</i><br>
<i>&gt;               other camera (such as the Kodak ones?) also use a format</i><br>
<i>&gt;               that's close to JPEG...</i><br>
<p>
We should finally add that.<br>
<p>
My idea about adding it would be to increase the version number, which<br>
can be queried at sane_init() time.<br>
<p>
If the frontend finds a sufficiently high version, it would assume<br>
that the SANE_Parameters struct is extended by a few fields like:<br>
<p>
SANE_String     mime_type;<br>
SANE_String     suggested_filename;<br>
<p>
This would effectively take care of all possible fileformats.<br>
<p>
The frontend code would have to be changed a bit like this:<br>
<p>
if (strcmp(param.mimetype,"application/SANE"))<br>
        save_directly_to_file(<br>
                make_path_suitable_for_host_os(<br>
                        param.suggested_filename)));<br>
else<br>
        do_the_same_as_before();<br>
<p>
This would also take care of the second suggestion in the file to use SANE<br>
for arbitrary datatypes.<br>
<p>
File size could be handled in a compatible way, by setting bytes_per_line<br>
and lines accordingly, that is usually to something like fsize(),1 or<br>
1,fsize().<br>
<p>
### using the lines==0 semantics that were resevred for handscanners, <br>
### we could handle yet unknown filesizes, which might occur for<br>
### compressed data formats.<br>
<p>
This would only be a minor modification to frontends and backends<br>
(even old frontends would handle new-style data somewhat correctly,<br>
if they would save it to a file directly without trying to convert/<br>
interpret it first). Most of our current front-ends afaik do a very<br>
simplistic "convert to pnm" which could easily be undone afterwards<br>
by a small script that simply removes the header.<br>
<p>
<p>
** Fri Oct 23 18:58:38 1998: David:<br>
<p>
What I'd like to see is the backend declaring what image format(s) it<br>
supports.  Similarly, the frontend would say what image format it<br>
wants.  Then you have a set of library routines that are filters,<br>
e.g., (input: JPG, output: RAW), (input: RAW, output: JPG).  So if<br>
there is a mismatch between backend and frontend format, you call a<br>
library routine that will construct a suitable pipeline of filters.<br>
<p>
The biggest issue is probably what to do for filters that need<br>
parameters (such as JPG smoothing &amp; quality settings).<br>
<p>
	---david<br>
<p>
** Sat Oct 24 12:42:25 1998: Andy:<br>
<p>
<i>&gt; What I'd like to see is the backend declaring what image format(s) it</i><br>
<i>&gt; supports.</i><br>
<p>
O.K. - as the user might want to select the format (regardless of what his<br>
frontend will understand), I suggest to just introduce a standard option<br>
for that.<br>
<p>
<i>&gt; Similarly, the frontend would say what image format it wants.</i><br>
<p>
I'd say it should parse the constraint list of said option and preselect<br>
the best of those it understands.<br>
<p>
<i>&gt; Then you have a set of library routines that are filters,</i><br>
<i>&gt; e.g., (input: JPG, output: RAW), (input: RAW, output: JPG).  So if</i><br>
<i>&gt; there is a mismatch between backend and frontend format, you call a</i><br>
<i>&gt; library routine that will construct a suitable pipeline of filters.</i><br>
<p>
Yes. Possible, though it might be hard to actually determine what the best<br>
path would be, i.e. which frontend-format/backend-format combination<br>
gives best quality. This might even depend on other source-options.<br>
<p>
<i>&gt; The biggest issue is probably what to do for filters that need</i><br>
<i>&gt; parameters (such as JPG smoothing &amp; quality settings).</i><br>
<p>
Regarding the filters issue I'd suggest to make use of one or more<br>
"passthrough" pseudo middle-ends that simply add to the abovementioned<br>
option and add their own options in as required by the conversion.<br>
<p>
Let's make up an example:<br>
<p>
We have a camera that outputs image/foo or image/bar type data on request.<br>
<p>
The frontend only understands image/gif and application/sane.<br>
<p>
We have a middle-end that can convert image/foo|bar to image/gif,<br>
image/jpeg, image/bla and application/sane.<br>
<p>
Now what happens:<br>
<p>
The frontend starts up and queries the camera for options. It sees the<br>
special option "transmission-format" and checks its constraint list.<br>
<p>
As there is no match between understood formats and transmittable formats,<br>
it tries (after asking the user ?) to reopen the selected source through<br>
the filter middleend.<br>
<p>
It again parses the special option which will now show foo,bar,gif,jpeg,bla<br>
and sane.<br>
Now it picks those it understands (in preferred order) and places them at<br>
the top of the constraint list and somehow marks them to the user (say by<br>
adding a "*" on text frontends or by making them green or whatever.<br>
<p>
Now to the user the select list looks like "sane,gif,foo,bar,jpeg,bla".<br>
<p>
Now say the user wants to have jpeg for some reason. So he selects the<br>
appropriate option. The middleend sees that, selects the most suitable<br>
source format (foo or bar) on the source and adds the required conversion<br>
options to the option list.<br>
<p>
If the user now asks for a scan, this request is passed through the<br>
middleend which sets up its filters in sane_read and builds a suitable<br>
parameter struct (as I suggested).<br>
<p>
The frontend sees (from the parameter struct) that is doesn't know the<br>
selected format, so it prompts the user for a filename (default from<br>
params) and just saves it.<br>
<p>
If the user had selected a known format, the frontend would proceed as<br>
usual, displaying the image etc.<br>
<p>
A reasonable addition to many frontends would be to have some kind of<br>
"mime.types" file (maybe even use it ?) that can be used to direct output<br>
to other programs as described there.<br>
<p>
Say if we get a audio/wav file, we parse mime.types and ask<br>
"I don't know mime-type audio/wav - what should I do ?<br>
  1. save to file<br>
  2. use mime.types (will run %s to display file)<br>
  3. cancel operation"<br>
<p>
** Wed Oct 28 07:11:49 1998: david:<br>
<p>
Hmmh, I see where you're coming from as far as support for different<br>
image data formats are concerned, but I'm not sure I like what you're<br>
proposing.  Here are some constraints I think we (ideally) should<br>
adhere to:<br>
<p>
        - existing frontends should continue to work (both in binary<br>
          form and in source form)<br>
<p>
        - existing backends should continue to work (both in binary<br>
          form and in source form)<br>
<p>
        - the user should not have to worry about image transmission<br>
          format<br>
<p>
I think we should agree on a set of image formats supported by SANE.<br>
E.g., format 0 is the existing "raw" format and uses a default file<br>
extension of ".pnm".  Format 1 could be GIF with file extension ".gif"<br>
etc.<br>
<p>
Suppose we introduce a new call:<br>
<p>
        SANE_Status sane_set_format (SANE_Word *format);<br>
<p>
When calling the value *FORMAT gives the format the frontend wants the<br>
image data in.  A special value of SANE_IMAGE_FORMAT_ANY indicates<br>
that the frontend can accept any format (as is the case for scanimage,<br>
for example).  Upon returning, *FORMAT gives the format that the<br>
backend is actually returning.  If the returned format doesn't match<br>
the wanted format, the frontend can either accept the backends choice<br>
(if the frontend can handle the format), abort with an error, or try<br>
another sane_set_format() call with a different wanted format to see<br>
if that format works better.<br>
<p>
Let's try your example:<br>
<p>
        - camera returns either FOO or BAR format<br>
        - the conversion meta-backend "cnv" can convert from FOO or BAR<br>
          to GIF, JPEG, and RAW<br>
<p>
Let's consider different frontends:<br>
<p>
        - In the case of GIMP, you always want RAW format so you'd<br>
          call sane_set_format() with a parameter of<br>
          SANE_IMAGE_FORMAT_RAW and if you don't get what you ask<br>
          for, you abort.  Since "cnv" can convert both FOO and BAR<br>
          to RAW, no problem exists.<br>
<p>
        - In the case of scanimage, you'd let the user specify the<br>
          format.  By default, you'd presumably pick the format based<br>
          on the filename extension (such as ".jpg") or through an<br>
          explicit option.  Then scanimage performs the appropriate<br>
          sane_set_format() call.  If the user doesn't care about the<br>
          format being used, scanimage could call sane_set_format()<br>
          with a value of SANE_IMAGE_FORMAT_ANY which lets the backend<br>
          pick the format that is most convenient (e.g., JPEG for a<br>
          JPG camera).<br>
<p>
          For example, if scanimage picks the JPEG format, cnv will<br>
          detect that the camera can't deliver JPEG (the camera<br>
          would return it's preferred format, e.g., FOO).  It would<br>
          then arrange for a translation from FOO to JPEG.<br>
<p>
Now, what happens if there is a version mismatch:<br>
<p>
        - if an old frontend talks to a new backend, the backend can<br>
          detect this since there won't be any calls to<br>
          sane_set_format().  In this case, the backend defaults to<br>
          returning the RAW format.  If a backend doesn't support RAW<br>
          (as might be the case for a JPEG camera), an old frontend<br>
          would not be able to directly talk to such a backend.<br>
          However, as long as a suitable conversion meta-backend<br>
          is interspersed, things will work happily (the meta-backend<br>
          sees the lack of a call to sane_set_format and defaults<br>
          to returning RAW, independent of what the real backend<br>
          delivers)<br>
<p>
        - if a new frontend talks to an old backend the<br>
          sane_set_format() call always returns RAW<br>
<p>
I think it would be nice to have a "cnv" meta-backend that would be<br>
fairly generic in that it would be easy to add new filters.  The<br>
filters would either convert to or from RAW format, so there really<br>
isn't much of an issue as to how to construct an "optimal" pipe (since<br>
the pipe consists either of exactly 0, 1, or 2 elements).<br>
<p>
** From <a href="mailto:davidm@mostang.com">davidm@mostang.com</a> Fri Oct 30 06:54:23 1998<br>
<p>
  Andy&gt; O.K. - would you mind using the mime-type ?<br>
<p>
No, I think it makes some sense to use MIME.<br>
<p>
  Andy&gt; My idea was, that a backend that offers formats that take<br>
  Andy&gt; parameters also exports those as options.<br>
<p>
Seems reasonable.<br>
<p>
<i>  &gt;&gt; Also, I think we may want to pick the name of the image format to</i><br>
<i>  &gt;&gt; be identical to the default filename extension</i><br>
<p>
  Andy&gt; This is why I was proposing to have a type filed as well as a<br>
  Andy&gt; "suggested filename". The latter especially makes sense for<br>
  Andy&gt; picture archives or such.<br>
<p>
Can't you get the suggested filename from the mime database?  There is<br>
an "exts" field.  Besides, I'm not really sure having a suggested<br>
filename extension is that important.  I don't particularly like<br>
programs that insist on using specific extensions (though it's OK if<br>
the _default_ to a sensible extension).<br>
<p>
  Andy&gt; Do we want SANE to be able to carry totally foreign or weird<br>
  Andy&gt; formats like say audio ?<br>
<p>
I think we shouldn't do anything that precludes this, but I also don't<br>
think it's anything that's worth spending a lot of effort on right<br>
now.  Introducing realtime issues could quickly make SANE so<br>
complicated that it's too bloated for simple scanning.  On the other<br>
hand, if for some reason video acquisition through SANE suddenly<br>
becomes a hot topic, we may want to be able to have at least some<br>
basic audio acquisition support.  But I would say we worry about this<br>
when we have a real need for it.<br>
<p>
To summarize our discussion: I don't have much of a problem using the<br>
"transmission-format" well-known option and whoever does the actual<br>
work, gets the final say.  If you want to do it (I won't have time any<br>
time soon), go wild!  Please be sure to update sane.tex etc as well so<br>
the docs stay in sync with the code (oh, I also think we should run<br>
things by sane-devel when there is a detailed proposal).<br>
<p>
** From <a href="mailto:becka@rz.uni-duesseldorf.de">becka@rz.uni-duesseldorf.de</a> Fri Oct 30 14:11:50 1998<br>
<p>
<i>&gt;   Andy&gt; O.K. - would you mind using the mime-type ?</i><br>
<i>&gt; No, I think it makes some sense to use MIME.</i><br>
<p>
O.K. - so we consider that as "decided".<br>
<p>
<i>&gt;   Andy&gt; My idea was, that a backend that offers formats that take</i><br>
<i>&gt;   Andy&gt; parameters also exports those as options.</i><br>
<i>&gt; Seems reasonable.</i><br>
<p>
O.K. - see my comments below.<br>
<p>
<i>&gt;   &gt;&gt; Also, I think we may want to pick the name of the image format to</i><br>
<i>&gt;   &gt;&gt; be identical to the default filename extension</i><br>
<i>&gt;   Andy&gt; This is why I was proposing to have a type filed as well as a</i><br>
<i>&gt;   Andy&gt; "suggested filename". The latter especially makes sense for</i><br>
<i>&gt;   Andy&gt; picture archives or such.</i><br>
<i>&gt;</i><br>
<i>&gt; Can't you get the suggested filename from the mime database?</i><br>
<p>
Yes, I think you can. But that wasn't, what I was trying to achieve with<br>
that. I wanted a full "suggested filename". That is, it should return<br>
"nice_picture_of_something.jpg". This is probably reasonable for<br>
transferring<br>
pictures from archives or such. You automatically get a reasonable filename.<br>
<p>
<i>&gt; There is an "exts" field.  Besides, I'm not really sure having a suggested</i><br>
<i>&gt; filename extension is that important.  I don't particularly like</i><br>
<i>&gt; programs that insist on using specific extensions (though it's OK if</i><br>
<i>&gt; the _default_ to a sensible extension).</i><br>
<p>
Yes. That is how I see it, too. You should get a reasonable default, but any<br>
program insisting or not asking for confirmation is broken IMO.<br>
<p>
<i>&gt;   Andy&gt; Do we want SANE to be able to carry totally foreign or weird</i><br>
<i>&gt;   Andy&gt; formats like say audio ?</i><br>
<i>&gt;</i><br>
<i>&gt; I think we shouldn't do anything that precludes this, but I also don't</i><br>
<i>&gt; think it's anything that's worth spending a lot of effort on right</i><br>
<i>&gt; now.</i><br>
<p>
Yes. Though I thought with using MIME, it should be pretty trivial.<br>
<p>
<i>&gt; Introducing realtime issues could quickly make SANE so</i><br>
<i>&gt; complicated that it's too bloated for simple scanning.</i><br>
<p>
Yes. I do not care for things like "streaming" audio/video. This is far too<br>
complex for SANE and requires too many changes. Just that you can transfer<br>
anything that could also be in a file and doesn't have other prerequisites.<br>
<p>
A bit of "netscape for scanners", you know. If someone build a file archive<br>
using SANE, he should be able add a few sound files or whatever, too.<br>
<p>
<i>&gt; On the other hand, if for some reason video acquisition through SANE</i><br>
<i>&gt; suddenly becomes a hot topic,</i><br>
<p>
I will probably write a driver for the Permedia II Graphics card I have<br>
which includes a Video grabber. But I won't care for live video, just for<br>
stills. SANE is just not suited to do that.<br>
<p>
A read-type interface isn't good. Video demands high bandwidth, and is thus<br>
best achieved via a mmap-type interface.<br>
<p>
<i>&gt; we may want to be able to have at least some basic audio acquisition</i><br>
<i>&gt; support.  But I would say we worry about this when we have a real need</i><br>
<i>&gt; for it.</i><br>
<p>
Yes. I'd say for now, everything that resembles a file transfer is o.k.<br>
Anything needing special transmission semantics like guaranteed bandwidth,<br>
bandwidth negotiation, etc. is out of bounds for now.<br>
<p>
------------ snap --------------<br>
<p>
O.K. - looks like I hadn't much to rant about.<br>
<p>
So the question is: Do you like the following general ideas:<br>
<p>
1. Add a well-known option to backends that can transfer in nonstandard<br>
formats, which allows to choose the format. This option shall be there, <br>
even if it only has one possible setting, as it is used to identify backends<br>
that use nonstandard formats.<br>
<p>
2. Write one or more filtering "middleends", that - similar to the net<br>
front-/backend - pass through a given source. Such Middleends would parse<br>
and upgrade the option described in 1 to hold all native formats _plus_<br>
all formats the middleend can convert the native formats to.<br>
<p>
3. Frontends that support this extension shall scan for the well-known<br>
option and mark up and default-select the format that is most convenient<br>
to them.<br>
<p>
4. Add a single new frametype SANE_MIME which describes a stream that looks<br>
like the output of a CGI-script, that would transfer the corresponding<br>
information. That is:<br>
<p>
------ snip --------<br>
Content-type: text/html<br>
More-headers: some extra hints<br>
<p>
data_in_free_streaming_format_until_eof.<br>
------ snap --------<br>
<p>
All headers are optional. Thus the minimal transmission consists of<br>
a single newline character (which serves as a header/body separator) <br>
followed by the raw data. It is not recommended to do so, though. <br>
At least Content-type: should be given.<br>
<p>
I propose two such headers that might be commonly used and should thus be<br>
parsed by the frontend. They are the same as what MIME-aware mailhandlers <br>
set for attachments :<br>
<p>
a) Content-type: mimetype/subtype[; optional_attribute=value]<br>
<p>
This header specifies the mimetype of the data that follows. The frontend<br>
should use that to look the type up in mime.types and prompt the user<br>
whether to "Save to file" (for which the extension info from the mime<br>
database is useful), "Open using application %s." (also from mime.types),<br>
or to cancel the transmission.<br>
Some frontends may also add "use internal viewer".<br>
<p>
Frontends that do not want to care about mime or asking the user should<br>
simply save away the stream "as-is" to a file, which allows for later <br>
processing with mime-aware tools.<br>
<p>
b) Content-Disposition: attachment; filename="suggested_filename"<br>
<p>
This header seems to be used to suggest a filename to mime-aware programs.<br>
Note, that the filename should be mangled by the frontend to conform to <br>
OS-dependent conventions and that care should be taken to:<br>
- Avoid security breaches using path separators, .., absolute paths, ... <br>
- Avoid similar attacks directed at creating files like .rhosts or<br>
  overwriting them.<br>
<p>
c) as the transport stream in SANE is assumed to be 8 bit clean (otherwise<br>
other frame formats won't work), I see little use for stuff like<br>
Content-Transfer-Encoding: base64<br>
and similar. <br>
<p>
5. As an alternative to the "inband" transmission suggested in 4., it would<br>
be possible to either add a new call to SANE or extend the get_parameters<br>
call to hold that information.<br>
Inband allows for an arbitrary number of Headers, while outband at getparm<br>
time seems a more natural approach from the code-flow and simplicity of<br>
parsing standpoint. In that case, we should simply limit ourselves to<br>
two strings containing mimetype and suggested filename.<br>
<p>
<p>
Comments very welcome.<br>
<p>
CU, ANdy<br>
<p>
<pre>
-- 
= Andreas Beck                    |  Email :  &lt;<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>&gt; =
<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="0152.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>Previous message:</b> <a href="0150.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>In reply to:</b> <a href="0147.html">Stephen Williams: "Re: [Fwd: Re: Discussion about SANE and TWAIN...]"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
<li> <b>Reply:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
<li> <b>Reply:</b> <a href="0165.html">Oliver Rauch: "Re: SANE V2 - past discussions. A summary."</a>
<!-- reply="end" -->
</ul>