kopia lustrzana https://gitlab.com/sane-project/website
116 wiersze
5.3 KiB
HTML
116 wiersze
5.3 KiB
HTML
<!-- received="Tue Aug 3 11:49:42 1999 PDT" -->
|
||
<!-- sent="Tue, 03 Aug 1999 20:39:00 +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 20:39:00 +0200</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#28">[ date ]</a><a href="index.html#28">[ thread ]</a><a href="subject.html#28">[ subject ]</a><a href="author.html#28">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0029.html">Oliver Rauch: "Re: RGBI (was Re: xsane-0.31 available)"</a>
|
||
<li> <b>Previous message:</b> <a href="0027.html">Nick Lamb: "Digital cameras (was Re: xsane-0.31 available)"</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="0033.html">Stephen Williams: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Nick Lamb wrote:<br>
|
||
<p>
|
||
<i>> On Tue, 3 Aug 1999, Andreas Rick wrote:</i><br>
|
||
<i>> > The problem with defining all thinkable formats is that it</i><br>
|
||
<i>> > adds a considerable amount of complexity to the frontend</i><br>
|
||
<i>> > which is only used for one specific backend which is able</i><br>
|
||
<i>> > to produce that one particular data-type.</i><br>
|
||
<i>></i><br>
|
||
<i>> And if we don't, we don't get any functionality for that particular data</i><br>
|
||
<i>> type. So I don't see what we're losing.</i><br>
|
||
<p>
|
||
If an image generating device uses its own data format there are<br>
|
||
two ways to handle this:<br>
|
||
1) The backend transforms it into a known data format<br>
|
||
2) The backend sends this data as a raw data to the frontend<br>
|
||
that saves it without any transformation.<br>
|
||
<p>
|
||
<p>
|
||
<i>> The infrared channel is not</i><br>
|
||
<i>> useful unless you know what to do with it -- it's not "REAL" image data</i><br>
|
||
<i>> in the usual sense.</i><br>
|
||
<p>
|
||
That is exactly what I say and so why should we add a special frame format<br>
|
||
for it if it does not make sense?<br>
|
||
<p>
|
||
<p>
|
||
<i>> It's a trap. The data flow depends only on number of channels, which</i><br>
|
||
<i>> we already know. So now I wonder why SANE defines all these FRAME types</i><br>
|
||
<i>> if not to tell me what's inside the frame...</i><br>
|
||
<p>
|
||
The backend does not tell you what is in the frame, it tells the frontend<br>
|
||
what is in the frame. And if you don`t tell me how xsane shall handle this,<br>
|
||
xsane will not handle this.<br>
|
||
<p>
|
||
<p>
|
||
<i>> If I treat an infrared scan from my Nikon Coolscan as simple RGBA, I</i><br>
|
||
<i>> will get nonsense out. The scanner knew what was in that data, and</i><br>
|
||
<i>> SANE knows right now. But with Oliver's design, suddenly SANE forgets</i><br>
|
||
<i>> this useful knowledge, and I just have junk in my alpha channel</i><br>
|
||
<p>
|
||
Ok SANE knows what is in that data.<br>
|
||
And I now ask again. How shall a frontend handle this knowledge?<br>
|
||
<p>
|
||
<i>> NB Just because you can't save "channel 4 is infrared" in PNG, doesn't</i><br>
|
||
<i>> mean you can't export the fouth channel directly to Gimp as</i><br>
|
||
<i>> "Additional channel: Name: Infrared, Colour: Orange 50%", and let a</i><br>
|
||
<i>> Gimp plug-in do the rest. You can even attach a parasite (in 1.1.x)</i><br>
|
||
<p>
|
||
The sense of SANE is not ONLY to be a plugin for the GIMP.<br>
|
||
We need to now what we have to do if we do not run as GIMP plugin!<br>
|
||
<p>
|
||
If we add a multi channel format with not-visible bands we should<br>
|
||
add a more general format that can handles (n) channels<br>
|
||
and the backend tells the frontend in a string what is in each channel.<br>
|
||
<p>
|
||
Then you also can write a backend for a (radio-) telescope and the (radio-)<br>
|
||
telescop backend tells the frontend:<br>
|
||
channel 1=gray<br>
|
||
channel 2=infrared<br>
|
||
channel 3=ultraviolett<br>
|
||
channel 4=gamma rays with wavelenght xyz<br>
|
||
channel 5=gamma rays with wacelength abc<br>
|
||
<p>
|
||
But we also need a format to save this channels.<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="0029.html">Oliver Rauch: "Re: RGBI (was Re: xsane-0.31 available)"</a>
|
||
<li> <b>Previous message:</b> <a href="0027.html">Nick Lamb: "Digital cameras (was Re: xsane-0.31 available)"</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="0033.html">Stephen Williams: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|