kopia lustrzana https://gitlab.com/sane-project/website
370 wiersze
20 KiB
HTML
370 wiersze
20 KiB
HTML
<!-- received="Wed Aug 18 18:43:52 1999 PDT" -->
|
||
<!-- sent="Thu, 19 Aug 1999 02:45:53 +0100 (GMT)" -->
|
||
<!-- name="Nick Lamb" -->
|
||
<!-- email="njl98r@ecs.soton.ac.uk" -->
|
||
<!-- subject="Re: SANE V2" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="19990816014243.A3689@rz.uni-duesseldorf.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>Thu, 19 Aug 1999 02:45:53 +0100 (GMT)</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#231">[ date ]</a><a href="index.html#231">[ thread ]</a><a href="subject.html#231">[ subject ]</a><a href="author.html#231">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0232.html">Mike Schmitz: "sane-umax"</a>
|
||
<li> <b>Previous message:</b> <a href="0230.html">Andreas Beck: "Re: Mustek Paragon 1200SP"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
On Mon, 16 Aug 1999, Andreas Beck wrote:<br>
|
||
<p>
|
||
<i>> Could you explain a little, what you mean ? I am afraid we are just</i><br>
|
||
<i>> misunderstanding each other. Note, that my mail forward was exactly this:</i><br>
|
||
<i>> A forward of vague thoughts, so I can understand, that it might cause</i><br>
|
||
<i>> confusion. I will try to clean that up a little now.</i><br>
|
||
<p>
|
||
Well, in part the mail was as hostile as it was because your "vague<br>
|
||
thoughts" gave the impression that SANE 1.x/2.0 has been discussed<br>
|
||
behind the scenes, when it should really have been a big open debate<br>
|
||
on SANE-devel as it is now. I don't like that very much :(<br>
|
||
<p>
|
||
But I wouldn't have written it at all if the recommendations weren't<br>
|
||
IMHO technically and politcally unsound.<br>
|
||
<p>
|
||
<i>> > MIME is not a solution to your problems, even the MIME types system is</i><br>
|
||
<i>> > probably overkill, but MIME itself is definitely *not* what SANE needs to</i><br>
|
||
<i>> > support the scanners we've been talking about on the list.</i><br>
|
||
<i>> </i><br>
|
||
<i>> I do not get you on that. The scanners we are talking about can produce</i><br>
|
||
<i>> compressed image formats. If I get you right (please correct me), you</i><br>
|
||
<i>> propose to handle this by adding a few well defined new frametypes. Right ?</i><br>
|
||
<p>
|
||
Yes. The contents of these frametypes will be exactly defined, preferably<br>
|
||
by an independent standards body. If someone asks on the list "What is<br>
|
||
SANE_FRAME_xxxx and how do I decode it", I want to be able to point at<br>
|
||
a public standards document.<br>
|
||
<p>
|
||
<i>> Now I propose to only add a single frametype, which redirects the exact</i><br>
|
||
<i>> description of what the datastream contains to some place, where there is </i><br>
|
||
<i>> "more space" than in a single integer.</i><br>
|
||
<p>
|
||
Whilst this gives you infinite flexibility, I think this is a poor trade<br>
|
||
for the uncertainty it foists on frontend writers, and worse -- users.<br>
|
||
<p>
|
||
<i>> 1. It is widely used.</i><br>
|
||
<p>
|
||
SANE is unlikely to be interoperable with any of the MIME-based systems<br>
|
||
which are currently deployed, mostly NNTP, HTTP, POP etc. So this is<br>
|
||
not IMHO a big advantage. Also, we only want to re-use the minimal<br>
|
||
subset mime types if I understand you correctly, not all of MIME.<br>
|
||
<p>
|
||
<i>> 2. It handles virtually all fileformats out there, and it can and will be </i><br>
|
||
<i>> extended as need arises.</i><br>
|
||
<p>
|
||
Handles here means nothing more than "has one or more names for". MIME<br>
|
||
doesn't _know_ anything about these file formats, although the more<br>
|
||
commonly used databases often recommend one or more file extensions for<br>
|
||
identifying data of that type.<br>
|
||
<p>
|
||
<i>> 3. It allows to use an existing external database for handling unknown</i><br>
|
||
<i>> formats.</i><br>
|
||
<p>
|
||
If you can give me a concrete and portable example of how SANE will<br>
|
||
"handle unknown formats" using MIME, I will accept this point. Until<br>
|
||
then I see no sign of this working for any of the other MIME aware<br>
|
||
applications on Unix, why would SANE be any different?<br>
|
||
<p>
|
||
<i>> If we allow any type to be transmitted, we as well to some extent encourage</i><br>
|
||
<i>> "bad" backends to be written, that will only send "application/something_</i><br>
|
||
<i>> weird" type data.</i><br>
|
||
<p>
|
||
It's worse than this, backends will send image/tiff and you will accept<br>
|
||
that, because after all it has a MIME type. Unfortunately TIFF is so<br>
|
||
poorly defined (along with many other types in the MIME database) that<br>
|
||
a frontend can only Save it to disk, and hope the user's got a copy of<br>
|
||
Gimp or some other highly tolerant image processing software.<br>
|
||
<p>
|
||
If you insist that backends stick to "accepted" MIME types, then you<br>
|
||
lose any advantages of MIME, but if you permit them to start lunacy<br>
|
||
like image/gif (or application/ms-word) then SANE becomes a joke --<br>
|
||
might as well just tell people to access scanners over HTTP.<br>
|
||
<p>
|
||
Note also that MIME itself has only VERY FEW formats, most of them<br>
|
||
live their lives as image/x-foo-bar-baz or more recently in the<br>
|
||
vendor controlled space. However, even those which are destined for<br>
|
||
standardisation start off as image/x-blah-blah, so you must continue<br>
|
||
to support this naming convention long after it expires. In MIME's<br>
|
||
intended applications this wasn't a problem, but it leaves a nasty<br>
|
||
taste in my mouth for SANE.<br>
|
||
<p>
|
||
<i>> This could be countered by requiring for a backend to be SANE compliant to</i><br>
|
||
<i>> support at least one of the RAW datatypes. This as well ensures continuing</i><br>
|
||
<i>> support for frontends, where saving to disk is not a good option, like</i><br>
|
||
<i>> when operating xscanimage in GIMP mode.</i><br>
|
||
<p>
|
||
I think most people are agreed that backends should send SANE 1.0 frame<br>
|
||
types (which I guess is what you mean by RAW) unless asked for something<br>
|
||
"better" by the frontend or user. You can do this regardless of whether<br>
|
||
SANE uses FRAME_JFIF or image/jpeg.<br>
|
||
<p>
|
||
<i>> > I'm not interested in having fairly bad support for digital cameras in SANE</i><br>
|
||
<i>> > when there's really good support for digital cameras in gPhoto. Since</i><br>
|
||
<i>> > we are now working toward TWAIN/Unix, it makes sense for gPhoto and SANE</i><br>
|
||
<i>> > to each implement TWAIN sources on top of their respective APIs.</i><br>
|
||
<i>> </i><br>
|
||
<i>> I actually do not see, why a digital camera needs to be handled differently.</i><br>
|
||
<i>> O.K. gPhoto exists, and it may well be good, but I do not see a principal</i><br>
|
||
<i>> problem to support digital cameras in SANE. </i><br>
|
||
<p>
|
||
DO NOT RE-INVENT THE WHEEL<br>
|
||
<p>
|
||
Developers won't work on SANE (no existing support, no frontend, no<br>
|
||
support in the API) when they can work on gPhoto (excellent support,<br>
|
||
good GUI and cmd-line tools, API designed for the job)<br>
|
||
<p>
|
||
Would you expect scanner developers to desert SANE and work on gPhoto?<br>
|
||
<p>
|
||
<i>> And - as nice as the interest of the TWAIN group in Unix is ... TWAIN is</i><br>
|
||
<i>> IMHO not the greatest thing since sliced bread. Have a look at their own</i><br>
|
||
<i>> standard. It is 526 pages. If the SANE standard were that big, I'd never</i><br>
|
||
<i>> even consider writing an application for it.</i><br>
|
||
<p>
|
||
Almost all of SANE is mandatory, almost all of TWAIN is optional -- not<br>
|
||
a fair comparison. Standards documents for stuff you use every single<br>
|
||
day are just as long, but you only read the essentials and everyone<br>
|
||
muddles along just fine ;)<br>
|
||
<p>
|
||
<i>> I think the main benefits we will get from connecting SANE to TWAIN is not</i><br>
|
||
<i>> getting a nicer and unified interface, but commercial (or other) Software</i><br>
|
||
<i>> being ported from Windows more easily and SANE being accessible by Windows</i><br>
|
||
<i>> software.</i><br>
|
||
<p>
|
||
Cool, whatever -- I think as a Gimp developer I'd like to be able to add<br>
|
||
a single Import feature and pick gPhoto or XSane or SaneSlidePro or<br>
|
||
whatever I had installed with TWAIN support. Nice to dream.<br>
|
||
<p>
|
||
<i>> O.K. - what is the problem with it ? I propose to _allow_ to transfer any</i><br>
|
||
<i>> file type. TWAIN supports audio. How do we make a real bridge layer, if we</i><br>
|
||
<i>> don't ?</i><br>
|
||
<p>
|
||
This is really horrible reasoning. If you want to support audio just<br>
|
||
because TWAIN can support audio, you should read those 500+ pages and<br>
|
||
come back when you're sober.<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>
|
||
<p>
|
||
The world is full of trade offs, the only protocol that comes to mind<br>
|
||
which transports "other file types at no cost" is HTTP. Unfortunately<br>
|
||
that's also a protocol so broken that it is on its third revision and<br>
|
||
still "considered harmful". Oh, and it uses MIME, what a co-incidence.<br>
|
||
<p>
|
||
<i>> Why ? Basically every device has "options" that can be read out and changed.</i><br>
|
||
<i>> Regarding device control, SANE is very universal. It could be used to</i><br>
|
||
<i>> tune your TV or drive a toaster. And actually I am using a variant of the</i><br>
|
||
<i>> SANE option control system in another project to handle IO-devices.</i><br>
|
||
<p>
|
||
It *could* be used to tune your TV, or drive a toaster. I *could* use<br>
|
||
a copy of Stroustup's "The C++ Programming Language" to learn C, but I<br>
|
||
am not suprised that Stroustrup doesn't recommend or support this.<br>
|
||
I'm happy that you re-used code from SANE in another project, if you<br>
|
||
think it's particularly useful you could split that code out and offer<br>
|
||
it to other free software projects.<br>
|
||
<p>
|
||
If, OTOH, you propose that this means SANE really is EVERYTHING WITH<br>
|
||
KNOBS ON NOW EASY, then I cannot agree. It's an imaging API, which<br>
|
||
concentrates on scanners and their ilk. Nothing more, nothing less.<br>
|
||
<p>
|
||
<i>> The only image-centric stuff in SANE is the start/getparm/read/stop stuff.</i><br>
|
||
<i>> </i><br>
|
||
<i>> That's o.k., as for the scope of SANE, this kind of interface makes sense.</i><br>
|
||
<p>
|
||
YES!<br>
|
||
<p>
|
||
<i>> Now we see demand for transferring data that is not accurately described by</i><br>
|
||
<i>> getparm. Thus I propose to do the simple thing and basically ignore getparm</i><br>
|
||
<i>> stuff and just transfer some streamed data.</i><br>
|
||
<p>
|
||
NO! You already said "for the scope of SANE, this kind of interface makes<br>
|
||
sense", but now you contradict yourself. You were right the first time.<br>
|
||
<p>
|
||
<i>> Now this alone would be not too good, as it leaves no idea what the data </i><br>
|
||
<i>> and its format actually is. </i><br>
|
||
<i>> Thus I propose to add a generic content description system for such data.</i><br>
|
||
<i>> Mime seems like a good choice, as said above. </i><br>
|
||
<p>
|
||
Even if MIME was a good choice, unless you take fairly strict control<br>
|
||
over the contents of the stream (as you would if accepting most of<br>
|
||
the recommended new FRAME_TYPEs) you will quickly have a bunch of<br>
|
||
proprietary apps communicating over a _read/_write API layer, not much<br>
|
||
more than standard I/O really -- and therefore a waste of time.<br>
|
||
<p>
|
||
<i>> This now allows to transfer any datatype that fits into a stream of bytes</i><br>
|
||
<i>> without need for more sophisticated stuff like bandwidth negotiation.</i><br>
|
||
<p>
|
||
Eh? Do not go down this road. sane_read(...) is defined over memory<br>
|
||
and therefore "bandwidth" is an irrelevant notion.<br>
|
||
<p>
|
||
<i>> However it has the drawback, that the frontend will usually not be able to</i><br>
|
||
<i>> interpret the data. This is acceptable when the frontend would save to file</i><br>
|
||
<i>> anyway, but not very good when it wants to display the result or hand it</i><br>
|
||
<i>> over to a client application like the GIMP.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Therefore, I propose, that every backend should have an option to select the</i><br>
|
||
<i>> output format. Every fully SANE compliant backend should support the option </i><br>
|
||
<i>> to transfer in RAW SANE format, to avoid this situation (where the frontend</i><br>
|
||
<i>> cannot make sense of the data, and cannot save it either for processing</i><br>
|
||
<i>> with tools that can) on user (or frontend) request.</i><br>
|
||
<p>
|
||
Yes, good -- this should be default, but stop calling it "RAW SANE"<br>
|
||
please, because I guess you just mean uncompressed like in SANE 1.0<br>
|
||
We agree about this, though perhaps not quite about how it is achieved<br>
|
||
<p>
|
||
<i>> To further simplify the process of writing front- or backends in a way that</i><br>
|
||
<i>> allows to finally generate RAW data (in the sense, that the frontend can</i><br>
|
||
<i>> make sense of the data) from common formats, I propose to have "middleends", </i><br>
|
||
<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>
|
||
<p>
|
||
Write middleends that do whatever you like. This has nothing much to do<br>
|
||
with the SANE standards process, because they're already permitted and<br>
|
||
even encouraged for some situations.<br>
|
||
<p>
|
||
<i>> This allows to keep a backend driver simple, as if it is sending a data</i><br>
|
||
<i>> type, for which a converting middleend exists, it doesn't need to worry</i><br>
|
||
<i>> about internal conversion (which would mean code duplication in all backends</i><br>
|
||
<i>> that happen to get a given kind of native input format from their HW). </i><br>
|
||
<p>
|
||
This can't work -- we've already agreed that backends must support RGB<br>
|
||
or GREY or something "natively" by default. So all backends must convert<br>
|
||
to RGB or GREY if the hardware can't do that itself.<br>
|
||
Converting to JFIF, G3/4/n or most other compressed formats inline is<br>
|
||
less silly, but I'll remain a sceptic until I see a good application.<br>
|
||
<p>
|
||
<i>> The other option to allow for full usage with compressed datatypes would be </i><br>
|
||
<i>> implementing conversion in the frontends. This is also not good, as it means </i><br>
|
||
<i>> code-duplication as well.</i><br>
|
||
<p>
|
||
I don't like this either. But it's OK because the backends will always<br>
|
||
to convert to something a frontend can be expected to understand (if<br>
|
||
you write a frontend that only reads 4bit GREY then you're on your own)<br>
|
||
<p>
|
||
<i>> So from the position of least code duplication, I think the middleends are a</i><br>
|
||
<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>
|
||
<p>
|
||
Tunability may/ may not exist in different hardware configurations and<br>
|
||
if JPEG compression isn't being done by the hardware, I'd prefer to see<br>
|
||
it in the frontend, where I can get a usable progress bar / do it offline<br>
|
||
or whatever. <br>
|
||
<p>
|
||
[Stuff about text support removed, I conceded this point after all that<br>
|
||
XML arrived in my mail, and so SANE_FRAME_ASCII it is]<br>
|
||
<p>
|
||
<i>> > application/sane? </i><br>
|
||
<i>> </i><br>
|
||
<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>
|
||
This doesn't fill me with confidence about your use of MIME. The objective<br>
|
||
here is not to clog up the world with a zillion mime types. It was also<br>
|
||
already explained that many new types (even compressed ones) would need<br>
|
||
the out-of-band data fields for decompression.<br>
|
||
<p>
|
||
<i>> I think the latter is more extensible, though it opens up more possibilities</i><br>
|
||
<i>> to "misuse" SANE for weird stuff, but I think that is a political rather</i><br>
|
||
<i>> than a technical question.</i><br>
|
||
<p>
|
||
Hmm, like this?<br>
|
||
<p>
|
||
This is FREE SOFTWARE, and as such it is not in our interests to promote<br>
|
||
closed protocols, undocumated formats etc. which undermine future work<br>
|
||
<p>
|
||
Imagine an entity "BG" which is hostile to free software. They want to<br>
|
||
write a proprietary scanning system, but they'd like to re-use our<br>
|
||
work and preferably use SANE's good name at first (until they can get<br>
|
||
50% market share) then kill SANE off later.<br>
|
||
<p>
|
||
Currently they can't write a SANE compliant backend or frontend without<br>
|
||
inviting competition from SANE developers or third parties who would<br>
|
||
support free software alternatives. They could deliberately break<br>
|
||
compatability, but that's not going to help them get market share.<br>
|
||
<p>
|
||
With my proposals this situation is preserved in SANE 1.1/2.0 because<br>
|
||
the new _FRAME types are all locked up by standards bodies who are<br>
|
||
committed to public standards and/or free software.<br>
|
||
<p>
|
||
With your proposal, "BG" need merely add the compliant, but proprietary<br>
|
||
image/x-bg-format to their backend and lock all advanced features in<br>
|
||
the frontend to the new format -- tada! Proprietary SANE :(<br>
|
||
<p>
|
||
<i>> And I definitely think, that except for special applications, that is</i><br>
|
||
<i>> customized frontends, the frontend should never have to care. It should</i><br>
|
||
<i>> either be able to force RAW transmission (via converting middleends if</i><br>
|
||
<i>> needed) to be able to do stuff to the resulting image to to revert to saving</i><br>
|
||
<i>> to file.</i><br>
|
||
<p>
|
||
No need for middleends here, backends MUST offer a SANE 1.0 FRAME format<br>
|
||
by default not least because this is polite. If you insist, this can be<br>
|
||
a SHOULD, but no-one writing drivers has objected to MUST.<br>
|
||
<p>
|
||
----<br>
|
||
<p>
|
||
<i>> To reapeat again the general outline of my approach:</i><br>
|
||
<i>> </i><br>
|
||
<i>> 1. Add a well-known option that allows to select the transmission format.</i><br>
|
||
<p>
|
||
Yes fine, exactly how to do this needs more thought<br>
|
||
<p>
|
||
<i>> 2. Add a single bew frametype that announces the transmission of arbitrarily</i><br>
|
||
<i>> formatted data. Add two identification fields somewhere that give the</i><br>
|
||
<i>> mimetype and optionally a proposed filename for the data, so one can </i><br>
|
||
<i>> correctly detect and handle the type of data. For "somewhere" I propose</i><br>
|
||
<i>> either the file stream itself, like it is done in metamail, which is a</i><br>
|
||
<i>> little awkward to handle in the frontend, or an extension to the parms </i><br>
|
||
<i>> struct which is easier to handle, but a bit less compatible.</i><br>
|
||
<p>
|
||
No. As far as I can tell, the only people who support this option (you<br>
|
||
included) won't have to live with the consequences. Are you working on<br>
|
||
any of the stuff for which the extended SANE_FRAME list was proposed?<br>
|
||
<p>
|
||
<i>> 3. To simplify backend generation, middleends should be allowed that can</i><br>
|
||
<i>> extend the available options for 1. by on-the-fly converting data from</i><br>
|
||
<i>> backend format to others.</i><br>
|
||
<p>
|
||
Today's SANE standard doesn't object to your writing on-the-fly middleend<br>
|
||
software, and I won't stop you either. As proposed though, the<br>
|
||
"from COMPRESSED to SANE 1.0" conversion is done in the backend anyway<br>
|
||
and the "SANE 1.0 to COMPRESSED" stuff seems better placed in the<br>
|
||
frontend, not least for performance reasons.<br>
|
||
<p>
|
||
Basically our differences could be summed up as:<br>
|
||
<p>
|
||
SANE_FRAME_BLAH vs image/x-wibble-foo<br>
|
||
<p>
|
||
Where SANE_FRAME_BLAH is defined by us, the SANE community and<br>
|
||
image/x-wibble-foo is defined by the next person who thinks they've<br>
|
||
uniquely discovered run length encoding and/or binary trees.<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="0232.html">Mike Schmitz: "sane-umax"</a>
|
||
<li> <b>Previous message:</b> <a href="0230.html">Andreas Beck: "Re: Mustek Paragon 1200SP"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|