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

<!-- received="Sat Aug 14 19:25:33 1999 PDT" -->
<!-- sent="Sun, 15 Aug 1999 03:24:55 +0100 (GMT)" -->
<!-- name="Nick Lamb" -->
<!-- email="njl98r@ecs.soton.ac.uk" -->
<!-- subject="Re: SANE V2" -->
<!-- id="" -->
<!-- inreplyto="m11FnzQ-000CDTC@hades.beck-sw.de" -->
<title>sane-devel: Re: SANE V2</title>
<h1>Re: SANE V2</h1>
<b>Nick Lamb</b> (<a href="mailto:njl98r@ecs.soton.ac.uk"><i>njl98r@ecs.soton.ac.uk</i></a>)<br>
<i>Sun, 15 Aug 1999 03:24:55 +0100 (GMT)</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#155">[ date ]</a><a href="index.html#155">[ thread ]</a><a href="subject.html#155">[ subject ]</a><a href="author.html#155">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0156.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>Previous message:</b> <a href="0154.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>In reply to:</b> <a href="0151.html">becka@rz.uni-duesseldorf.de: "SANE V2 - past discussions. A summary."</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0165.html">Oliver Rauch: "Re: SANE V2 - past discussions. A summary."</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
On Sun, 15 Aug 1999 <a href="mailto:becka@rz.uni-duesseldorf.de">becka@rz.uni-duesseldorf.de</a> wrote:<br>
<p>
<i>&gt; So the question is: Do you like the following general ideas:</i><br>
<p>
No. That was the worst proposal for SANE 2.0 that I can imagine.<br>
<p>
Here is my counter-proposal, I think it's simpler and remains in the<br>
spirit of SANE 1.0 <br>
<p>
-----------<br>
<p>
1. Add several new SANE_FRAME_ (...) formats<br>
<p>
Each frame format would be for a standards-based image compression format<br>
in common use on scanners. It should be possible to save the data stream<br>
exactly as transmitted into a file, and load that file into any suitable<br>
image viewer or editor.<br>
<p>
So far we've seen JFIF and the G3 series discussed on this list, unless<br>
anyone steps forward I would guess that's all there is for now.<br>
<p>
[In addition we ought to agree about SANE_FRAME_RGBI/ RGBA/ RGBD/ whatever]<br>
<p>
2. Define appropriate behaviour for new frames<br>
<p>
The existing frame types have obvious meanings for bps, lines etc.<br>
but these may not be useful in the same way for compressed data. After<br>
looking at the existing software, and the new compressed formats, we<br>
need to define some appropriate behaviour in the SANE standard<br>
<p>
3. Add extra well-known options<br>
<p>
Currently defined are: resolution, preview, tl-x, tl-y, br-x, br-y, (0)<br>
<p>
I propose that we add (at least):<br>
<p>
adf "Indicates whether or not to use the ADF" (Boolean, default FALSE)<br>
This option should only exist for scanners which ACTUALLY HAVE an ADF,<br>
when set TRUE a new document should be loaded for each scan.<br>
<p>
mode "Controls scan mode (e.g. lineart, color)"<br>
Every backend SHOULD offer at least one "well known" mode, such as Color<br>
but they can also offer their own modes.<br>
<p>
depth "Controls number of bits per sample (e.g. 10)"<br>
Backends should offer this option only if you can _change_ the bitdepth<br>
because there is _already_ a mechanism for discovering the bitdepth.<br>
<p>
compression "Controls image compression (e.g. JPEG, G3, NONE)"<br>
Backends should offer this option if they support standards-based<br>
compression.<br>
<p>
filename "Recommended file name (e.g. buttercup.jpg)"<br>
Backends with appropriate information can recommend a filename for<br>
storing this image on disk.<br>
<p>
Some other options can be added if appropriate, though some currently<br>
listed in saneopts.h really belong in the individual backends.<br>
<p>
4. Tighten up the standard<br>
<p>
Comparing the standard with current practises, and looking back through<br>
sane-devel over the months/ years, reveals that some parts of the<br>
standard aren't as clear as they could be or have become out of date.<br>
<p>
Behaviour for "preview" should be more clearly explained, as should<br>
2--7 bit and 9--16 bit sample sizes, and there will need to be more<br>
explanation about SANE_FRAME formats once more are in place.<br>
<p>
5. Add an explicit clause for future unsupported frame types<br>
<p>
Recommend that in future, frontends which encounter an unsupported<br>
frame type should (order of preference)<br>
<p>
(a) Offer a choice of what to do to the operator<br>
(b) Save all the raw data to a file<br>
(c) Give an error and exit gracefully<br>
<p>
I would expect that xscanimage and XSane should manage (a) while<br>
scanimage would achieve (b) at least optionally from the command line<br>
Third party products, especially plug-ins of any kind would do (c)<br>
<p>
---------<br>
<p>
Well, what do you think?<br>
<p>
Nick.<br>
<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="0156.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>Previous message:</b> <a href="0154.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>In reply to:</b> <a href="0151.html">becka@rz.uni-duesseldorf.de: "SANE V2 - past discussions. A summary."</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0165.html">Oliver Rauch: "Re: SANE V2 - past discussions. A summary."</a>
<!-- reply="end" -->
</ul>