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

<!-- received="Tue Aug  3 14:51:24 1999 PDT" -->
<!-- sent="Tue, 03 Aug 1999 23:45:25 +0200" -->
<!-- name="Oliver Rauch" -->
<!-- email="oliver.rauch@Wolfsburg.DE" -->
<!-- subject="Re: SANE_FRAME Formats (was Re: xsane-0.31 available)" -->
<!-- id="" -->
<!-- inreplyto="SANE_FRAME Formats (was Re: xsane-0.31 available)" -->
<title>sane-devel: Re: SANE_FRAME Formats (was Re: xsane-0.31 available)</title>
<h1>Re: SANE_FRAME Formats (was Re: xsane-0.31 available)</h1>
<b>Oliver Rauch</b> (<a href="mailto:oliver.rauch@Wolfsburg.DE"><i>oliver.rauch@Wolfsburg.DE</i></a>)<br>
<i>Tue, 03 Aug 1999 23:45:25 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#36">[ date ]</a><a href="index.html#36">[ thread ]</a><a href="subject.html#36">[ subject ]</a><a href="author.html#36">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0037.html">Stephen Williams: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<li> <b>Previous message:</b> <a href="0035.html">Patrick L. McGillan: "Basic info needed"</a>
<li> <b>Maybe in reply to:</b> <a href="0019.html">Andreas Rick: "SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0040.html">Tom Martone: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Stephen Williams wrote:<br>
<p>
<i>&gt; <a href="mailto:rickand@gemse.fr">rickand@gemse.fr</a> said:</i><br>
<i>&gt; &gt; The problem with defining all thinkable formats is that it adds a</i><br>
<i>&gt; &gt; considerable amount of complexity to the frontend which is only used</i><br>
<i>&gt; &gt; for one specific backend which is able to produce that one particular</i><br>
<i>&gt; &gt; data-type.</i><br>
<i>&gt;</i><br>
<i>&gt; There should be some way for the frontend and backend to negotiate formats,</i><br>
<i>&gt; and a small core set of formats that both must support. For example, if</i><br>
<i>&gt; my scanner-with-compression driver is hooked to a frontend that knows</i><br>
<i>&gt; of none of its high performance formats, then the driver, to be compliant,</i><br>
<i>&gt; should be able to resort to RGB or somesuch.</i><br>
<p>
Good point.<br>
The frontend is already able to ask for the frame formats the backend uses:<br>
if the backend makes the different formats available as "mode"<br>
(where normally Grayscale, Halftone and RGB can be selected)<br>
and defines modes like "Color RGB" or "Color JFIF", the frontend could select<br>
each mode and read the parameter block and take a look at the<br>
frame format. If it supports the frame format, it enables that mode, if<br>
it does not support that frame format, it hides that mode.<br>
<p>
Does the backend need to know what a frontend can handle?<br>
<p>
<i>&gt; So, I think there must be a small set of "must have" frame formats,</i><br>
<i>&gt; and a larger set of "standard optional" formats that handle some of</i><br>
<i>&gt; the common and obvious formats, like JPEG.</i><br>
<p>
I don`t know if we really need "must have" frame formats.<br>
If there is a frontend that only can handle JPEG-frames, where<br>
is the problem?<br>
<p>
<p>
<i>&gt; The negotiation process could</i><br>
<i>&gt; also allow for a set of local or private formats that are outside any</i><br>
<i>&gt; sort of standard definition.</i><br>
<p>
Hm, sounds a bit strange to define "private" formats in the<br>
SANE STANDARD.<br>
<p>
<p>
<i>&gt; If all applications must support any combination of frame types, then</i><br>
<i>&gt; the application writers will go nuts. If, on the other hand the scanner</i><br>
<i>&gt; vendors must work with an excessively short list of formats, they will</i><br>
<i>&gt; not be able to demonstrate the value of their nifty expensive equipment.</i><br>
<p>
I think we must find a good way between that.<br>
If a frontend is not able to handle a special file format: ok - no problem<br>
We should add formats that will be used by different backends.<br>
That will e.g. be some formats for still cameras.<br>
<p>
If there is one backend that uses a prorietary format it has to convert<br>
it into another format or it has to pass it trough in raw format.<br>
<p>
<p>
<i>&gt; Maybe there should be some standard option that the application can query</i><br>
<i>&gt; to get a list of all the supported frame formats from the scanner. This</i><br>
<i>&gt; would be sufficient, and allow new frame type to be added in the future</i><br>
<i>&gt; without breaking compatibility.</i><br>
<p>
Adding a new format does not break the compatibility.<br>
If a backend sends an image in an unknown frame format,<br>
the frontend simply does say "don't know to handle SANE_FRAME_xyz".<br>
<p>
Bye<br>
Oliver<br>
<p>
<pre>
--
EMAIL: <a href="mailto:Oliver.Rauch@Wolfsburg.DE">Oliver.Rauch@Wolfsburg.DE</a>
WWW: <a href="http://www.wolfsburg.de/~rauch">http://www.wolfsburg.de/~rauch</a>
<p>
<p>
<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="0037.html">Stephen Williams: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<li> <b>Previous message:</b> <a href="0035.html">Patrick L. McGillan: "Basic info needed"</a>
<li> <b>Maybe in reply to:</b> <a href="0019.html">Andreas Rick: "SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0040.html">Tom Martone: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
<!-- reply="end" -->
</ul>