kopia lustrzana https://gitlab.com/sane-project/website
196 wiersze
10 KiB
HTML
196 wiersze
10 KiB
HTML
<!-- received="Sun Aug 29 19:58:44 1999 PDT" -->
|
||
<!-- sent="Mon, 30 Aug 1999 03:58:33 +0100 (GMT)" -->
|
||
<!-- name="Nick Lamb" -->
|
||
<!-- email="njl98r@ecs.soton.ac.uk" -->
|
||
<!-- subject="Re: SANE V2 - again..." -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="37C965B2.E33288E6@satzbau-gmbh.de" -->
|
||
<title>sane-devel: Re: SANE V2 - again...</title>
|
||
<h1>Re: SANE V2 - again...</h1>
|
||
<b>Nick Lamb</b> (<a href="mailto:njl98r@ecs.soton.ac.uk"><i>njl98r@ecs.soton.ac.uk</i></a>)<br>
|
||
<i>Mon, 30 Aug 1999 03:58:33 +0100 (GMT)</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#330">[ date ]</a><a href="index.html#330">[ thread ]</a><a href="subject.html#330">[ subject ]</a><a href="author.html#330">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0331.html">Milon Firikis: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0329.html">Strider Centaur: "Re: Mustek MFS-6000CX and Adaptec 1505"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
I'm away for next week. I was hoping to get another draft sane.tex<br>
|
||
out of my way before I left, but it didn't happen. This is my last<br>
|
||
comments until I return.<br>
|
||
<p>
|
||
On Sun, 29 Aug 1999, abel deuring wrote:<br>
|
||
<p>
|
||
<i>> Another somewhat exotic example are some old drum scanners:</i><br>
|
||
<i>> At least the combination of a Crosfield Magnascan scanner</i><br>
|
||
<i>> and a Sun IPC box with special control software for this</i><br>
|
||
<i>> scanner produces TIFF files with CMYK data. I don't know, if</i><br>
|
||
<i>> the RGB -> CMYK transformation is done in the IPC box or in</i><br>
|
||
<i>> the scanner, but since these scanners were some years ago</i><br>
|
||
<i>> directly connected to imagesetters, I assume that the RGB -></i><br>
|
||
<i>> CMYK transformation is done by the scanner. While it is</i><br>
|
||
<i>> mathematically quite easy to make again a CMYK -> RGB</i><br>
|
||
<i>> transformation, this means a loss of information. A good</i><br>
|
||
<i>> CMYK representation knows about specific details of the</i><br>
|
||
<i>> printing technology: CMYK data for an ink jet printer can be</i><br>
|
||
<i>> quite different from CMYK data for an offset printing press.</i><br>
|
||
<p>
|
||
CMYK was discussed before, the main thing I remember was - What<br>
|
||
the hell is in the black channel? In print processes it makes<br>
|
||
sense to have K vs CMY but in scanning it's far from obvious...<br>
|
||
TIFF is just nasty. Don't believe me? Read libtiff and/or my<br>
|
||
Gimp plug-in :)<br>
|
||
<p>
|
||
<i>> A more common situation might be a scanner / backend</i><br>
|
||
<i>> combination which delivers colour calibrated data, generally</i><br>
|
||
<i>> represented in the XYZ colour space or colour spaces derived</i><br>
|
||
<i>> from XYZ, like CIELab. While up to now nobody in the Sane</i><br>
|
||
<i>> community has cared about colour calibration, this could</i><br>
|
||
<i>> become an issue, if Sane is implemented for Mac OS X: Since</i><br>
|
||
<i>> Mac OS X is basically a Unix, it should be not too difficult</i><br>
|
||
<i>> to get Sane running. On the other hand, the prepress</i><br>
|
||
<i>> industry, the stronghold of Mac computers, is increasingly</i><br>
|
||
<i>> using colour calibration, so that Sane would be not that</i><br>
|
||
<i>> useful for many Mac users, if an integration of colour</i><br>
|
||
<i>> calibration into Sane turns out to be quite difficult. More</i><br>
|
||
<i>> informations on colour calibration can be found at</i><br>
|
||
<i>> http:://www.color.org (especially about the ICC standard),</i><br>
|
||
<i>> and at <a href="http://www.fogra.org">http://www.fogra.org</a> (unfortunately, the latter site</i><br>
|
||
<i>> contains much of its informations only in German).</i><br>
|
||
<p>
|
||
Interesting... do we have anyone who has such a beast and can<br>
|
||
describe what's really coming out of the hardware? Of course in<br>
|
||
the normal case calibration is outside of SANE's remit (though<br>
|
||
it needn't always remain that way I suppose) but if some hardware<br>
|
||
can send us sRGB, CIE or whatever pre-calibrated that is cool.<br>
|
||
<p>
|
||
<i>> So far about requirements on new or additional data</i><br>
|
||
<i>> representations and contents. Now, what is the attraction of</i><br>
|
||
<i>> the Sane standard and of the Sane software package? For me,</i><br>
|
||
<i>> as a person working on a backend for an "ordinary" flatbed</i><br>
|
||
<i>> scanner, there are three points:</i><br>
|
||
<i>> </i><br>
|
||
<i>> - The "OS abstraction layer" sanei_scsi.[ch] enables the</i><br>
|
||
<i>> backend to run on a number of different Unixes.</i><br>
|
||
<i>> </i><br>
|
||
<i>> - The API defined by the Sane standard is simple in the</i><br>
|
||
<i>> sense the I do not have to deal with a user interface (with</i><br>
|
||
<i>> the exception of declaring a bunch of options);</i><br>
|
||
<i>> </i><br>
|
||
<i>> - but it is nevertheless quite powerful in that a backend</i><br>
|
||
<i>> can declare a wide variety of options, so that the</i><br>
|
||
<i>> capabilities of a scanner can be easily presented to a</i><br>
|
||
<i>> frontend and a user.</i><br>
|
||
<i>> </i><br>
|
||
<i>> n interesting detail about the last point is that the</i><br>
|
||
<i>> frontendA generally does not know anything about the meaning</i><br>
|
||
<i>> of the options. (The "well known options" like tl-x are of</i><br>
|
||
<i>> course an exception.)</i><br>
|
||
<p>
|
||
Yes, but there are some assumptions which tend to made above and<br>
|
||
beyond the well-known options. Some of these should be formalised<br>
|
||
and some might need to be deprecated.<br>
|
||
<p>
|
||
<i>> A similar viewpoint could be taken on the scan data: At</i><br>
|
||
<i>> least a generic frontend like xscanimage or scanimage does</i><br>
|
||
<i>> not need to know anything about the data content: It's task</i><br>
|
||
<i>> is mainly to control the scanner and to feed the scan data</i><br>
|
||
<i>> to another program or into a file. (Oliver's xsane is</i><br>
|
||
<i>> somewhat different, since it is able to perform</i><br>
|
||
<i>> manipulations on the scan data, like gamma correction.)</i><br>
|
||
<p>
|
||
We should expect MORE power in frontends in the future, so XSane<br>
|
||
will be _typical_ in the future. I think stuff for film scanning<br>
|
||
and for high-speed document scanners is planned. OCR should<br>
|
||
happen one of these long days. It's not just the user who cares<br>
|
||
what's in the datastream -- the application cares just as much.<br>
|
||
<p>
|
||
<i>> Regarding scanner control, a preview should of course be</i><br>
|
||
<i>> possible, if this makes sense for the particular device, and</i><br>
|
||
<i>> in this case a backend should be able to deliver preview</i><br>
|
||
<i>> data in a "well known format" like SANE_FRAME_RGB or</i><br>
|
||
<i>> SANE_FRAME_GRAY. 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>
|
||
<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. In the latter</i><br>
|
||
<i>> case, the backend must support the frontend by giving hints</i><br>
|
||
<i>> how to handle the data. At present, I don't know if these</i><br>
|
||
<i>> hints should have the form of MIME types, as Andy suggested,</i><br>
|
||
<i>> or if there might be better ways. Probably the most complex</i><br>
|
||
<i>> question is how to handle several sets of different data for</i><br>
|
||
<i>> one scan, like the additional bar code data produced by</i><br>
|
||
<i>> these high speed scanners: Should all these data be</i><br>
|
||
<i>> considered as one data stream by the backend / frontend API,</i><br>
|
||
<i>> or should there be provisions to allow multiple data</i><br>
|
||
<i>> streams? I am sure that Tom Martone and other people working</i><br>
|
||
<i>> with this class of scanners have already thought about it,</i><br>
|
||
<i>> so I would like hear comments from them.</i><br>
|
||
<p>
|
||
There is a provision for multiple data frames, so the question<br>
|
||
is: Should we use it for this in SANE 2.0, and I think the<br>
|
||
answer has to be "Yes", unless there's a better idea.<br>
|
||
<p>
|
||
(SANE 1.0 doesn't use multiple data frames for this purpose,<br>
|
||
but it does provide them for several other reasons anyway)<br>
|
||
<p>
|
||
<i>> Finally, I think that a major revision of Sane should</i><br>
|
||
<i>> include language support. I know some users who would really</i><br>
|
||
<i>> appreciate it, if it would be possible to display e.g. the</i><br>
|
||
<i>> resolution option as "Aufl<66>sung".</i><br>
|
||
<p>
|
||
Yes, this would be very nice.<br>
|
||
<p>
|
||
<i>> A very rough, incomplete and perhaps too simple suggestion</i><br>
|
||
<i>> for two library functions:</i><br>
|
||
<i>> </i><br>
|
||
<i>> Instead of simply displaying a variable of the type</i><br>
|
||
<i>> SANE_String, a frontend should call a function</i><br>
|
||
<i>> </i><br>
|
||
<i>> SANE_String* sane_translate_from_english(const SANE_String* text,</i><br>
|
||
<i>> const SANE_String* language)</i><br>
|
||
<p>
|
||
I think this is just gettext, but someone else will no doubt explain<br>
|
||
why gettext doesn't buy much for SANE. Alternatively maybe you mean<br>
|
||
to pass this function through to the backend?<br>
|
||
<p>
|
||
<i>> When handing a SANE_String value to the backend, a frontend</i><br>
|
||
<i>> should call</i><br>
|
||
<i>> </i><br>
|
||
<i>> SANE_String* sane_translate_into_english(const SANE_String* text,</i><br>
|
||
<i>> const SANE_String* language)</i><br>
|
||
<p>
|
||
Not sure what this is for. Hopefully someone else can address it.<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="0331.html">Milon Firikis: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0329.html">Strider Centaur: "Re: Mustek MFS-6000CX and Adaptec 1505"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|