kopia lustrzana https://gitlab.com/sane-project/website
74 wiersze
3.7 KiB
HTML
74 wiersze
3.7 KiB
HTML
<!-- received="Sun Feb 28 18:55:47 1999 PST" -->
|
|
<!-- sent="Sun, 28 Feb 1999 18:55:43 -0800" -->
|
|
<!-- name="David Mosberger-Tang" -->
|
|
<!-- email="David.Mosberger@acm.org" -->
|
|
<!-- subject="Re: 16-bit frames and interleaving" -->
|
|
<!-- id="199903010255.SAA09343@panda.mostang.com" -->
|
|
<!-- inreplyto="199902281935.LAA04809@panda.mostang.com" -->
|
|
<title>sane-devel: Re: 16-bit frames and interleaving</title>
|
|
<h1>Re: 16-bit frames and interleaving</h1>
|
|
<b>David Mosberger-Tang</b> (<a href="mailto:David.Mosberger@acm.org"><i>David.Mosberger@acm.org</i></a>)<br>
|
|
<i>Sun, 28 Feb 1999 18:55:43 -0800</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#255">[ date ]</a><a href="index.html#255">[ thread ]</a><a href="subject.html#255">[ subject ]</a><a href="author.html#255">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0256.html">Rick Knight: "Re: Acer 310s"</a>
|
|
<li> <b>Previous message:</b> <a href="0254.html">Wolfgang Goeller: "Re: Acer 310s"</a>
|
|
<li> <b>In reply to:</b> <a href="0225.html">David Mosberger-Tang: "Re: 16-bit frames and interleaving"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
<i>>>>>> On Mon, 01 Mar 1999 01:02:18 +0100, Oliver Rauch <<a href="mailto:oliver.rauch@Wolfsburg.DE">oliver.rauch@Wolfsburg.DE</a>> said:</i><br>
|
|
<p>
|
|
Oliver> I don`t have the sane-specs in mind at that point, but I<br>
|
|
Oliver> don`t understand why a 16-bit gamma upload to the scanner is<br>
|
|
Oliver> byte-order independent and a 16-bit download from the<br>
|
|
Oliver> backend to the frontend is must take care of the<br>
|
|
Oliver> byte-order/transform it.<br>
|
|
<p>
|
|
Let me try to explain better: most backends do NOT need to worry about<br>
|
|
byte-order---they can simply assume that the image data is in their<br>
|
|
native byte-order. The only exception is the "net" backend since if<br>
|
|
it runs on a host whose byte-order differs from that of the server,<br>
|
|
then the "net" backend needs to adjust the byte order.<br>
|
|
<p>
|
|
For control data (such as gamma-tables), the convention is that the<br>
|
|
network protocol always uses big-endian (aka network byteorder) and<br>
|
|
this is taken care of by the "wire" protocol (look at<br>
|
|
sanei_code_bin.c, for example). The reason we don't use the same<br>
|
|
approach for the image data is that image data tends to be much<br>
|
|
bigger, so you want to be as efficient as possible. With a "receiver<br>
|
|
makes right" approach where the server always sends data in its native<br>
|
|
format, you only get the byte-swapping overhead when strictly<br>
|
|
necessary (i.e., when there is an endianness mismatch). This is<br>
|
|
particularly important given that most machines these days are<br>
|
|
little-endian.<br>
|
|
<p>
|
|
Oliver> Byt the way, I don`t think that it is good for efficency<br>
|
|
Oliver> that that byte-order must be swapped twice sometimes:<br>
|
|
Oliver> scanner-byte-order to backend-byte-order to<br>
|
|
Oliver> frontend-byte-order.<br>
|
|
<p>
|
|
Exactly. But for control data, the overhead tends to be small enough<br>
|
|
not to warrant the extra complexity.<br>
|
|
<p>
|
|
--david<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="0256.html">Rick Knight: "Re: Acer 310s"</a>
|
|
<li> <b>Previous message:</b> <a href="0254.html">Wolfgang Goeller: "Re: Acer 310s"</a>
|
|
<li> <b>In reply to:</b> <a href="0225.html">David Mosberger-Tang: "Re: 16-bit frames and interleaving"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|