> So the question is: Do you like the following general ideas:
No. That was the worst proposal for SANE 2.0 that I can imagine.
Here is my counter-proposal, I think it's simpler and remains in the
spirit of SANE 1.0
-----------
1. Add several new SANE_FRAME_ (...) formats
Each frame format would be for a standards-based image compression format
in common use on scanners. It should be possible to save the data stream
exactly as transmitted into a file, and load that file into any suitable
image viewer or editor.
So far we've seen JFIF and the G3 series discussed on this list, unless
anyone steps forward I would guess that's all there is for now.
[In addition we ought to agree about SANE_FRAME_RGBI/ RGBA/ RGBD/ whatever]
2. Define appropriate behaviour for new frames
The existing frame types have obvious meanings for bps, lines etc.
but these may not be useful in the same way for compressed data. After
looking at the existing software, and the new compressed formats, we
need to define some appropriate behaviour in the SANE standard
3. Add extra well-known options
Currently defined are: resolution, preview, tl-x, tl-y, br-x, br-y, (0)
I propose that we add (at least):
adf "Indicates whether or not to use the ADF" (Boolean, default FALSE)
This option should only exist for scanners which ACTUALLY HAVE an ADF,
when set TRUE a new document should be loaded for each scan.
mode "Controls scan mode (e.g. lineart, color)"
Every backend SHOULD offer at least one "well known" mode, such as Color
but they can also offer their own modes.
depth "Controls number of bits per sample (e.g. 10)"
Backends should offer this option only if you can _change_ the bitdepth
because there is _already_ a mechanism for discovering the bitdepth.
compression "Controls image compression (e.g. JPEG, G3, NONE)"
Backends should offer this option if they support standards-based
compression.
filename "Recommended file name (e.g. buttercup.jpg)"
Backends with appropriate information can recommend a filename for
storing this image on disk.
Some other options can be added if appropriate, though some currently
listed in saneopts.h really belong in the individual backends.
4. Tighten up the standard
Comparing the standard with current practises, and looking back through
sane-devel over the months/ years, reveals that some parts of the
standard aren't as clear as they could be or have become out of date.
Behaviour for "preview" should be more clearly explained, as should
2--7 bit and 9--16 bit sample sizes, and there will need to be more
explanation about SANE_FRAME formats once more are in place.
5. Add an explicit clause for future unsupported frame types
Recommend that in future, frontends which encounter an unsupported
frame type should (order of preference)
(a) Offer a choice of what to do to the operator
(b) Save all the raw data to a file
(c) Give an error and exit gracefully
I would expect that xscanimage and XSane should manage (a) while
scanimage would achieve (b) at least optionally from the command line
Third party products, especially plug-ins of any kind would do (c)
---------
Well, what do you think?
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com