> I know. That's why I'm sad that you (and apparently David) are proposing
> to butcher SANE in the way you described. If you take the course you
> originally proposed, I genuinely believe it will be the end of SANE.
Could you explain a little, what you mean ? I am afraid we are just
misunderstanding each other. Note, that my mail forward was exactly this:
A forward of vague thoughts, so I can understand, that it might cause
confusion. I will try to clean that up a little now.
Please read through this mail entirely, and then comment in a detailed way.
I tried to list up all advantages/disadvantages/..., but I may well have
missed some points. It wouldn't be unusual, that I have overlooked something
important, just because an idea looked so appealing to me.
> MIME is not a solution to your problems, even the MIME types system is
> probably overkill, but MIME itself is definitely *not* what SANE needs to
> support the scanners we've been talking about on the list.
I do not get you on that. The scanners we are talking about can produce
compressed image formats. If I get you right (please correct me), you
propose to handle this by adding a few well defined new frametypes. Right ?
Now I propose to only add a single frametype, which redirects the exact
description of what the datastream contains to some place, where there is
"more space" than in a single integer.
The reason why I propose to use Mime instead of adding more frametypes is:
1. It is widely used.
2. It handles virtually all fileformats out there, and it can and will be
extended as need arises.
3. It allows to use an existing external database for handling unknown
formats.
The disadvantage I see is more a political, than a technical issue:
If we allow any type to be transmitted, we as well to some extent encourage
"bad" backends to be written, that will only send "application/something_
weird" type data.
This could be countered by requiring for a backend to be SANE compliant to
support at least one of the RAW datatypes. This as well ensures continuing
support for frontends, where saving to disk is not a good option, like
when operating xscanimage in GIMP mode.
> I'm not interested in having fairly bad support for digital cameras in SANE
> when there's really good support for digital cameras in gPhoto. Since
> we are now working toward TWAIN/Unix, it makes sense for gPhoto and SANE
> to each implement TWAIN sources on top of their respective APIs.
I actually do not see, why a digital camera needs to be handled differently.
O.K. gPhoto exists, and it may well be good, but I do not see a principal
problem to support digital cameras in SANE.
And - as nice as the interest of the TWAIN group in Unix is ... TWAIN is
IMHO not the greatest thing since sliced bread. Have a look at their own
standard. It is 526 pages. If the SANE standard were that big, I'd never
even consider writing an application for it.
I think the main benefits we will get from connecting SANE to TWAIN is not
getting a nicer and unified interface, but commercial (or other) Software
being ported from Windows more easily and SANE being accessible by Windows
software.
> We *could* implement anything as a SANE backend, and I guarantee that you
> will find at least one person who'll ask for HTML, MP3 and probably for
> a new API better suited to the Amiga. I'm not interested in fantasy, I
> want the next generation SANE to be a useful and effective tool.
O.K. - what is the problem with it ? I propose to _allow_ to transfer any
file type. TWAIN supports audio. How do we make a real bridge layer, if we
don't ?
I am fully with you, that SANE is intended for scanners, and should target
images, but if we can add other file types at no cost, Why not ?
> It's worth stating here that right from the start I was suprised that
> SANE had xcam, because the SANE API is exactly the wrong way to do that
> sort of thing.
Why ? Basically every device has "options" that can be read out and changed.
Regarding device control, SANE is very universal. It could be used to
tune your TV or drive a toaster. And actually I am using a variant of the
SANE option control system in another project to handle IO-devices.
The only image-centric stuff in SANE is the start/getparm/read/stop stuff.
That's o.k., as for the scope of SANE, this kind of interface makes sense.
Now we see demand for transferring data that is not accurately described by
getparm. Thus I propose to do the simple thing and basically ignore getparm
stuff and just transfer some streamed data.
Now this alone would be not too good, as it leaves no idea what the data
and its format actually is.
Thus I propose to add a generic content description system for such data.
Mime seems like a good choice, as said above.
This now allows to transfer any datatype that fits into a stream of bytes
without need for more sophisticated stuff like bandwidth negotiation.
However it has the drawback, that the frontend will usually not be able to
interpret the data. This is acceptable when the frontend would save to file
anyway, but not very good when it wants to display the result or hand it
over to a client application like the GIMP.
Therefore, I propose, that every backend should have an option to select the
output format. Every fully SANE compliant backend should support the option
to transfer in RAW SANE format, to avoid this situation (where the frontend
cannot make sense of the data, and cannot save it either for processing
with tools that can) on user (or frontend) request.
To further simplify the process of writing front- or backends in a way that
allows to finally generate RAW data (in the sense, that the frontend can
make sense of the data) from common formats, I propose to have "middleends",
that can attach between a front and a backend (like the net stuff or the
dll backend does) and can convert from common filetypes to SANE RAW.
This allows to keep a backend driver simple, as if it is sending a data
type, for which a converting middleend exists, it doesn't need to worry
about internal conversion (which would mean code duplication in all backends
that happen to get a given kind of native input format from their HW).
The other option to allow for full usage with compressed datatypes would be
implementing conversion in the frontends. This is also not good, as it means
code-duplication as well.
So from the position of least code duplication, I think the middleends are a
good solution. It also gives tuneability for the parameters (jpeg-quality)
in a simple way, as a middleend can extend the optionlist.
> > With more intelligence being moved into the scanners, we might get
> > text/plain or text/rtf in the future. TWAIN has provisions to read barcodes,
> > so their translation is probably also directly provided by some scanners.
> If the scanner wants to speak text, it's probably beyond the territory
> we should sensibly stake out for SANE. At that point you're looking at a
> whole new class of device IMHO.
No. If I got the guy with that high-speed scanning stuff right in his last
mail, he says, that those scanners can detect barcoded "batch separators".
Now if he makes a custom frontend, he will want to be able to detect those
and probably even make use of the data.
I imagine his purpose is document archiving. Now he could just put a bunch
of pages in the scanner with such a separator page on top. The code on the
page would tell the frontend where to store/send the resulting files.
Now if we can convey that information "inline", this would allow to just
stack more pages with separators on top, and stuff gets sorted in
automatically.
> > I would simply consider them undefined and filled with values that will
> > allow for smooth transfer even with old code. They are of no interest to
> > you for the transmission. And any external format like JPG will have the
> > information we transfer outband for application/sane inband, that is,
> > included in the file stream itself.
> application/sane?
That the "proposed MIME-type" of the current data stream. It is using extra
outband data (width and height) from the getparms operation, which all
other formats we are talking of do not need, as they contain that inband.
> > > filename "Recommended file name (e.g. buttercup.jpg)"
> > > Backends with appropriate information can recommend a filename for
> > > storing this image on disk.
> > Pardon me ? This is precisely what I was proposing ... ???
> > Could you consider reading what others propose before judging ?
> That was one option, the one you seemed to favour less,
Two. The other one was selecting the transmission format.
> and for only a small part of your proposal.
Yes. I agree with you, that the "filename" part is not very useful,
just as you say:
> I don't think "filename" will be used much anyway, because most of
> the devices I can envision being used with SANE don't have a useful
> filename to suggest.
Right. Archives maybe, which is actually stretching SANE a bit. And some
devices might want to suggest e.g. the time of capture as a default
filename or something, but other than that ...
The more important part of my proposal was the other option I quoted from
your proposal: File transmission format.
So I don't see much difference between our proposals, except for using
multiple frametypes vs. a single universal frametype.
I think the latter is more extensible, though it opens up more possibilities
to "misuse" SANE for weird stuff, but I think that is a political rather
than a technical question.
For the frontend I do not see much difference between
switch(parms.frametype) {
case FT_JPG:...
case FT_TIFFG3:...
}
and
if (strcmp(parms.mimetype,"image/jpeg")==0) {
...
} else if (strcmp(parms.mimetype,"image/tiffg3")==0) {
...
}
And I definitely think, that except for special applications, that is
customized frontends, the frontend should never have to care. It should
either be able to force RAW transmission (via converting middleends if
needed) to be able to do stuff to the resulting image to to revert to saving
to file.
Please comment on my points. I'd like to precisely know, where you see
problems. I am very willing to listen to arguments, but I need to know what
the exact problems with my approach are.
To reapeat again the general outline of my approach:
1. Add a well-known option that allows to select the transmission format.
2. Add a single bew frametype that announces the transmission of arbitrarily
formatted data. Add two identification fields somewhere that give the
mimetype and optionally a proposed filename for the data, so one can
correctly detect and handle the type of data. For "somewhere" I propose
either the file stream itself, like it is done in metamail, which is a
little awkward to handle in the frontend, or an extension to the parms
struct which is easier to handle, but a bit less compatible.
3. To simplify backend generation, middleends should be allowed that can
extend the available options for 1. by on-the-fly converting data from
backend format to others.
CU, ANdy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com