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

<!-- received="Sun Aug 29 10:03:22 1999 PDT" -->
<!-- sent="Sun, 29 Aug 1999 18:54:10 +0200" -->
<!-- name="abel deuring" -->
<!-- email="a.deuring@satzbau-gmbh.de" -->
<!-- subject="SANE V2 - again..." -->
<!-- id="" -->
<!-- inreplyto="" -->
<title>sane-devel: SANE V2 - again...</title>
<h1>SANE V2 - again...</h1>
<b>abel deuring</b> (<a href="mailto:a.deuring@satzbau-gmbh.de"><i>a.deuring@satzbau-gmbh.de</i></a>)<br>
<i>Sun, 29 Aug 1999 18:54:10 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#327">[ date ]</a><a href="index.html#327">[ thread ]</a><a href="subject.html#327">[ subject ]</a><a href="author.html#327">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0328.html">Mike Lucente: "Re: Mustek MFS-6000CX and Adaptec 1505"</a>
<li> <b>Previous message:</b> <a href="0326.html">Hugo van der Kooij: "Re: Mustek MFS-6000CX and Adaptec 1505"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0331.html">Milon Firikis: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0331.html">Milon Firikis: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0332.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0334.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0335.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0336.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0339.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0340.html">Milon Firikis: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0343.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0344.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0345.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0346.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0348.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0349.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0351.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0356.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0360.html">Tom Martone: "Re: SANE V2 - again..."</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Hi all!<br>
<p>
During the last weeks, some really interesting<br>
discussions have started in this mailing list, especially<br>
the one about interoperability of SANE and TWAIN, and the<br>
one about the future of the SANE standard.<br>
<p>
The latter became unfortunately quite personal, and some<br>
mails were not very fair, in my opinion. The debate about<br>
mime types versus more frame types has thereby reached a<br>
dead end, and I don't want to make an immediate contribution<br>
to this discussion. Instead, I'll try to go a step back to<br>
discuss, which new demands appeared, and to outline how<br>
these demands might be approached with Sane.<br>
<p>
The debate about additional frame formats vs. mime types<br>
arose from three points:<br>
<p>
(a) that some high speed scanners and digital cameras<br>
deliver their image data in compressed format.<br>
<p>
(b) that some scanners deliver data in addition to the<br>
usual RGB or gray scale data, like some slide scanners,<br>
which produce infrared data, or high speed scanners, which<br>
produce additional data in ASCII format. Another example<br>
might be a digital camera being able to deliver the date and<br>
time, when a photo was taken.<br>
<p>
(c) if Sane should be extended to "completely different<br>
data" like audio.<br>
<p>
(b) and (c) are about data content, while (a) is about data<br>
representation.<br>
<p>
Regarding (c), I don't have any ideas and no emotions, and I<br>
will therefore not make any further comments.<br>
<p>
Please correct me, if there were more topics -- I was in<br>
vacations, and I had not enough time to read all mails sent<br>
this list during the last weeks very carefully.<br>
<p>
Regarding data representation, my first thinking was that<br>
the communication between a backend and a frontend becomes<br>
unneccesarily complicated, if there is more than one<br>
representation. On the other hand, it does not make not much<br>
sense to receive compressed data from a scanner, let the<br>
backend decompress this data, and let the frontend compress<br>
the data again. Further, decompressing JPEG data and<br>
compressing it again into this format might cause a loss of<br>
information. Nevertheless I think that the Sane standard<br>
should focus mainly on its current internal format<br>
definitions. I will come back to the question of different<br>
data formats vs. keeping the standard simple later.<br>
<p>
The question how to handle data content "beyond RGB and gray<br>
scale" is far more difficult. Any attempt to map these data<br>
somehow into know formats seems to me questionable, even in<br>
the comparatively simple case of an infrared channel of a<br>
slide scanner: Of course it is possible to declare this<br>
channel to be the alpha channel, and this will indeed<br>
improve the image quality to some extent. But this is not a<br>
proper solution: An alpha channel simply cuts out scratches<br>
and dust from the image data. A proper solution would be,<br>
that a function (or a special program) interprets the data<br>
from the infrared channel as "replace the RGB data of the<br>
pixels marked in the infrared channel as dust or scratches<br>
by interpolating their neighboring 'valid' pixels". (A<br>
short digression: Since slide scanners are quite common<br>
meanwhile, it might be helpful to have a library function in<br>
the Sane package which does the "dust removal". Such a<br>
function is capable to convert the RGB/infrared data<br>
properly into pure RGB data. But this does not need to be<br>
covered by the Sane standard: Even the far more important<br>
functions from sanei_scsi.c are not covered by it.)<br>
<p>
Even more exotic situations have been mentioned during the<br>
debate, like scanners delivering spectral data from IR to<br>
UV. This data can of course not be represented as RGB -- but<br>
it might be useful to convert thiy type of data into RGB for<br>
a preview.<br>
<p>
Another somewhat exotic example are some old drum scanners:<br>
At least the combination of a Crosfield Magnascan scanner<br>
and a Sun IPC box with special control software for this<br>
scanner produces TIFF files with CMYK data. I don't know, if<br>
the RGB -&gt; CMYK transformation is done in the IPC box or in<br>
the scanner, but since these scanners were some years ago<br>
directly connected to imagesetters, I assume that the RGB -&gt;<br>
CMYK transformation is done by the scanner. While it is<br>
mathematically quite easy to make again a CMYK -&gt; RGB<br>
transformation, this means a loss of information. A good<br>
CMYK representation knows about specific details of the<br>
printing technology: CMYK data for an ink jet printer can be<br>
quite different from CMYK data for an offset printing press.<br>
<p>
A more common situation might be a scanner / backend<br>
combination which delivers colour calibrated data, generally<br>
represented in the XYZ colour space or colour spaces derived<br>
from XYZ, like CIELab. While up to now nobody in the Sane<br>
community has cared about colour calibration, this could<br>
become an issue, if Sane is implemented for Mac OS X: Since<br>
Mac OS X is basically a Unix, it should be not too difficult<br>
to get Sane running. On the other hand, the prepress<br>
industry, the stronghold of Mac computers, is increasingly<br>
using colour calibration, so that Sane would be not that<br>
useful for many Mac users, if an integration of colour<br>
calibration into Sane turns out to be quite difficult. More<br>
informations on colour calibration can be found at<br>
http:://www.color.org (especially about the ICC standard),<br>
and at <a href="http://www.fogra.org">http://www.fogra.org</a> (unfortunately, the latter site<br>
contains much of its informations only in German).<br>
<p>
So far about requirements on new or additional data<br>
representations and contents. Now, what is the attraction of<br>
the Sane standard and of the Sane software package? For me,<br>
as a person working on a backend for an "ordinary" flatbed<br>
scanner, there are three points:<br>
<p>
- The "OS abstraction layer" sanei_scsi.[ch] enables the<br>
  backend to run on a number of different Unixes.<br>
<p>
- The API defined by the Sane standard is simple in the<br>
sense the I do not have to deal with a user interface (with<br>
the exception of declaring a bunch of options);<br>
<p>
- but it is nevertheless quite powerful in that a backend<br>
can declare a wide variety of options, so that the<br>
capabilities of a scanner can be easily presented to a<br>
frontend and a user.<br>
<p>
n interesting detail about the last point is that the<br>
frontendA generally does not know anything about the meaning<br>
of the options. (The "well known options" like tl-x are of<br>
course an exception.)<br>
<p>
A similar viewpoint could be taken on the scan data: At<br>
least a generic frontend like xscanimage or scanimage does<br>
not need to know anything about the data content: It's task<br>
is mainly to control the scanner and to feed the scan data<br>
to another program or into a file. (Oliver's xsane is<br>
somewhat different, since it is able to perform<br>
manipulations on the scan data, like gamma correction.)<br>
Regarding scanner control, a preview should of course be<br>
possible, if this makes sense for the particular device, and<br>
in this case a backend should be able to deliver preview<br>
data in a "well known format" like SANE_FRAME_RGB or<br>
SANE_FRAME_GRAY. Therefore, my suggestion is to split the<br>
requirements for the scan data format and scan data content<br>
into two parts:<br>
<p>
- The preview data may be only in SANE_FRAME_GRAY,<br>
SANE_FRAME_RGB, SANE_FRAME_RED, ...GREEN, ...BLUE. If<br>
necessary, the backend must transform some other internal<br>
data content or data representation into one of these<br>
formats. (For "better known" data representations like<br>
xyz-compression and "better known" data contents like RGB +<br>
"infrared for dust removal" library functions might be<br>
developed which transform the scan data into RGB or gray<br>
scale.<br>
<p>
- The "real" scan data may be either in the same format as<br>
the preview data (if this is reasonable for the particular<br>
device), or in a format chosen by the backend. In the latter<br>
case, the backend must support the frontend by giving hints<br>
how to handle the data. At present, I don't know if these<br>
hints should have the form of MIME types, as Andy suggested,<br>
or if there might be better ways. Probably the most complex<br>
question is how to handle several sets of different data for<br>
one scan, like the additional bar code data produced by<br>
these high speed scanners: Should all these data be<br>
considered as one data stream by the backend / frontend API,<br>
or should there be provisions to allow multiple data<br>
streams? I am sure that Tom Martone and other people working<br>
with this class of scanners have already thought about it,<br>
so I would like hear comments from them.<br>
<p>
Finally, I think that a major revision of Sane should<br>
include language support. I know some users who would really<br>
appreciate it, if it would be possible to display e.g. the<br>
resolution option as "Aufl<66>sung".<br>
<p>
A very rough, incomplete and perhaps too simple suggestion<br>
for two library functions:<br>
<p>
Instead of simply displaying a variable of the type<br>
SANE_String, a frontend should call a function<br>
<p>
  SANE_String* sane_translate_from_english(const SANE_String* text,<br>
                                           const SANE_String* language)<br>
<p>
and display the result of this function.<br>
<p>
When handing a SANE_String value to the backend, a frontend<br>
should call<br>
<p>
  SANE_String* sane_translate_into_english(const SANE_String* text,<br>
                                           const SANE_String* language)<br>
<p>
To avoid failures of shell scripts like "xerox", the latter<br>
function must of course be able to accept English texts as<br>
input without trying to translate them.<br>
<p>
Abel<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="0328.html">Mike Lucente: "Re: Mustek MFS-6000CX and Adaptec 1505"</a>
<li> <b>Previous message:</b> <a href="0326.html">Hugo van der Kooij: "Re: Mustek MFS-6000CX and Adaptec 1505"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0331.html">Milon Firikis: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0331.html">Milon Firikis: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0332.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0334.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0335.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0336.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0339.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0340.html">Milon Firikis: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0343.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0344.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0345.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0346.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0348.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0349.html">abel deuring: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0351.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0356.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
<li> <b>Reply:</b> <a href="0360.html">Tom Martone: "Re: SANE V2 - again..."</a>
<!-- reply="end" -->
</ul>