kopia lustrzana https://gitlab.com/sane-project/website
154 wiersze
8.8 KiB
HTML
154 wiersze
8.8 KiB
HTML
|
<!-- received="Mon Aug 30 10:02:51 1999 PDT" -->
|
|||
|
|
<!-- sent="Mon, 30 Aug 1999 18:46:35 +0200" -->
|
|||
|
|
<!-- name="abel deuring" -->
|
|||
|
|
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
|||
|
|
<!-- 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>abel deuring</b> (<a href="mailto:a.deuring@satzbau-gmbh.de"><i>a.deuring@satzbau-gmbh.de</i></a>)<br>
|
|||
|
|
<i>Mon, 30 Aug 1999 18:46:35 +0200</i>
|
|||
|
|
<p>
|
|||
|
|
<ul>
|
|||
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#339">[ date ]</a><a href="index.html#339">[ thread ]</a><a href="subject.html#339">[ subject ]</a><a href="author.html#339">[ author ]</a>
|
|||
|
|
<!-- next="start" -->
|
|||
|
|
<li> <b>Next message:</b> <a href="0340.html">Milon Firikis: "Re: SANE V2 - again..."</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0338.html">ml@vianetinc.com: "Mustek MFS-6000CX, once again please."</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="0340.html">Milon Firikis: "Re: SANE V2 - again..."</a>
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|
|||
|
|
<!-- body="start" -->
|
|||
|
|
Nick Lamb 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>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> CMYK was discussed before, the main thing I remember was - What</i><br>
|
|||
|
|
<i>> the hell is in the black channel? In print processes it makes</i><br>
|
|||
|
|
<i>> sense to have K vs CMY but in scanning it's far from obvious...</i><br>
|
|||
|
|
<i>> TIFF is just nasty. Don't believe me? Read libtiff and/or my</i><br>
|
|||
|
|
<i>> Gimp plug-in :)</i><br>
|
|||
|
|
<p>
|
|||
|
|
I know that CMYK data is not that easy to handle. But as I said, the<br>
|
|||
|
|
example of CMYK data from a scanner is somewhat exotic. I tried to<br>
|
|||
|
|
mention it only as just _one_ example of a data format not yet discussed<br>
|
|||
|
|
regarding further development of the Sane standard. If anybody is really<br>
|
|||
|
|
interested in a more detailed discussion about CMYK, its importance in<br>
|
|||
|
|
the [pre]press industry, things like undercolour removal, black<br>
|
|||
|
|
generation, algorithms for CMYK -> RGB conversion or whatever, please<br>
|
|||
|
|
let me know. But I think that this leads away from the issue "Sane<br>
|
|||
|
|
Version 2".<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>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Interesting... do we have anyone who has such a beast and can</i><br>
|
|||
|
|
<i>> describe what's really coming out of the hardware? Of course in</i><br>
|
|||
|
|
<i>> the normal case calibration is outside of SANE's remit (though</i><br>
|
|||
|
|
<i>> it needn't always remain that way I suppose) but if some hardware</i><br>
|
|||
|
|
<i>> can send us sRGB, CIE or whatever pre-calibrated that is cool.</i><br>
|
|||
|
|
<p>
|
|||
|
|
I did not claim that there are any devices delivering data in XYZ or any<br>
|
|||
|
|
other device independent colour space on their output connector. But<br>
|
|||
|
|
considering Mac OS X, it is worth to discuss, if Sane can and/or should<br>
|
|||
|
|
be _prepared_ for colour calibration, or if this completely unnecessary.<br>
|
|||
|
|
Of course, a complete system to handle colour calibration is far beyond<br>
|
|||
|
|
the scope of Sane -- but scanning software can be integrated into a<br>
|
|||
|
|
colour management system.<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>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> We should expect MORE power in frontends in the future, so XSane</i><br>
|
|||
|
|
<i>> will be _typical_ in the future. I think stuff for film scanning</i><br>
|
|||
|
|
<i>> and for high-speed document scanners is planned. OCR should</i><br>
|
|||
|
|
<i>> happen one of these long days. It's not just the user who cares</i><br>
|
|||
|
|
<i>> what's in the datastream -- the application cares just as much.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Maybe that an OCR program will include its own interface to Sane<br>
|
|||
|
|
backends -- but right now I don't why an OCR developer should do this<br>
|
|||
|
|
works, since xscanimage and xsane already can do the job.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> There is a provision for multiple data frames, so the question</i><br>
|
|||
|
|
<i>> is: Should we use it for this in SANE 2.0, and I think the</i><br>
|
|||
|
|
<i>> answer has to be "Yes", unless there's a better idea.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> (SANE 1.0 doesn't use multiple data frames for this purpose,</i><br>
|
|||
|
|
<i>> but it does provide them for several other reasons anyway)</i><br>
|
|||
|
|
<p>
|
|||
|
|
If I saw only an already (or mainly) solved problem, the better.<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>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes, this would be very nice.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<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>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> I think this is just gettext, but someone else will no doubt explain</i><br>
|
|||
|
|
<i>> why gettext doesn't buy much for SANE. Alternatively maybe you mean</i><br>
|
|||
|
|
<i>> to pass this function through to the backend?</i><br>
|
|||
|
|
<p>
|
|||
|
|
If I saw only an already solved problem, the better.<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="0340.html">Milon Firikis: "Re: SANE V2 - again..."</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0338.html">ml@vianetinc.com: "Mustek MFS-6000CX, once again please."</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="0340.html">Milon Firikis: "Re: SANE V2 - again..."</a>
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|