kopia lustrzana https://gitlab.com/sane-project/website
124 wiersze
5.3 KiB
HTML
124 wiersze
5.3 KiB
HTML
<!-- received="Mon Aug 30 03:32:01 1999 PDT" -->
|
||
<!-- sent="Mon, 30 Aug 1999 13:31:29 +0300" -->
|
||
<!-- name="Milon Firikis" -->
|
||
<!-- email="milonf@ariadne-t.gr" -->
|
||
<!-- subject="Re: SANE V2 - again..." -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="SANE V2 - again..." -->
|
||
<title>sane-devel: Re: SANE V2 - again...</title>
|
||
<h1>Re: SANE V2 - again...</h1>
|
||
<b>Milon Firikis</b> (<a href="mailto:milonf@ariadne-t.gr"><i>milonf@ariadne-t.gr</i></a>)<br>
|
||
<i>Mon, 30 Aug 1999 13:31:29 +0300</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#331">[ date ]</a><a href="index.html#331">[ thread ]</a><a href="subject.html#331">[ subject ]</a><a href="author.html#331">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0332.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0330.html">Nick Lamb: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0327.html">abel deuring: "SANE V2 - again..."</a>
|
||
<!-- nextthread="start" -->
|
||
<li> <b>Next in thread:</b> <a href="0332.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
abel deuring wrote:<br>
|
||
<i>> </i><br>
|
||
<i>> Hi all!</i><br>
|
||
<i>> </i><br>
|
||
<i>> During the last weeks, some really interesting</i><br>
|
||
<i>> discussions have started in this mailing list, especially</i><br>
|
||
<i>> the one about interoperability of SANE and TWAIN, and the</i><br>
|
||
<i>> one about the future of the SANE standard.</i><br>
|
||
<i>> </i><br>
|
||
<i>> The latter became unfortunately quite personal, and some</i><br>
|
||
<i>> mails were not very fair, in my opinion. The debate about</i><br>
|
||
<i>> mime types versus more frame types has thereby reached a</i><br>
|
||
<i>> dead end, and I don't want to make an immediate contribution</i><br>
|
||
<i>> to this discussion. Instead, I'll try to go a step back to</i><br>
|
||
<i>> discuss, which new demands appeared, and to outline how</i><br>
|
||
<i>> these demands might be approached with Sane.</i><br>
|
||
<p>
|
||
You are the voice of reason in person :-)<br>
|
||
<p>
|
||
[snip a lot of background info]<br>
|
||
<p>
|
||
<i>> Therefore, my suggestion is to split the</i><br>
|
||
<i>> requirements for the scan data format and scan data content</i><br>
|
||
<i>> into two parts:</i><br>
|
||
<i>> </i><br>
|
||
<i>> - The preview data may be only in SANE_FRAME_GRAY,</i><br>
|
||
<i>> SANE_FRAME_RGB, SANE_FRAME_RED, ...GREEN, ...BLUE. If</i><br>
|
||
<i>> necessary, the backend must transform some other internal</i><br>
|
||
<i>> data content or data representation into one of these</i><br>
|
||
<i>> formats. (For "better known" data representations like</i><br>
|
||
<i>> xyz-compression and "better known" data contents like RGB +</i><br>
|
||
<i>> "infrared for dust removal" library functions might be</i><br>
|
||
<i>> developed which transform the scan data into RGB or gray</i><br>
|
||
<i>> scale.</i><br>
|
||
<p>
|
||
YES!!!!. I agree though I do not volunteer to write the above libraries<br>
|
||
:-)<br>
|
||
<p>
|
||
The point is:<br>
|
||
<p>
|
||
Why a frontend needs to know what is the content of data?<br>
|
||
<p>
|
||
PREVIEW is the one reason, but I can't find anything else. I you have a<br>
|
||
specialized application which does OCR for example it should be able to<br>
|
||
read from a file anyway. If, let's say, the OCR application wants to be<br>
|
||
a SANE frontend, then let it be, but it should read in a standard<br>
|
||
compliant way, anyway. A frontend needs to know how to read the data<br>
|
||
only to preview them. If I am wrong please raise hands.<br>
|
||
<p>
|
||
<i>> </i><br>
|
||
<i>> - The "real" scan data may be either in the same format as</i><br>
|
||
<i>> the preview data (if this is reasonable for the particular</i><br>
|
||
<i>> device), or in a format chosen by the backend.</i><br>
|
||
<p>
|
||
[snip]<br>
|
||
<p>
|
||
Yes, TRUE, SANE_TRUE, I agree.<br>
|
||
<p>
|
||
[snip]<br>
|
||
<p>
|
||
<i>> </i><br>
|
||
<i>> Finally, I think that a major revision of Sane should</i><br>
|
||
<i>> include language support.</i><br>
|
||
<p>
|
||
I won't comment on the language support. But since we are talking about<br>
|
||
new documented capabilities (SANE standard revision) I would like to see<br>
|
||
some means for:<br>
|
||
<p>
|
||
-reading files with array of numbers as information. This would be<br>
|
||
useful to read/save/store<br>
|
||
-Gamma Tables<br>
|
||
-Calibration vectors (3x256)<br>
|
||
-Color Correction tables (3x3 integer matrix)<br>
|
||
-Halftone patterns (4x4, or 8x8 PGM images)<br>
|
||
<p>
|
||
Some of them may be "well known options" like the Gamma tables.<br>
|
||
Currently SANE provides some way of downloading GAMMA tables but the<br>
|
||
procedure is not well documented IIRC.<br>
|
||
<p>
|
||
Apple backend needs all of them for the later models of apple.<br>
|
||
Unfortunately I don't have access to any of them.<br>
|
||
<p>
|
||
MF<br>
|
||
<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="0332.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0330.html">Nick Lamb: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0327.html">abel deuring: "SANE V2 - again..."</a>
|
||
<!-- nextthread="start" -->
|
||
<li> <b>Next in thread:</b> <a href="0332.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|