Oliver> I don`t have the sane-specs in mind at that point, but I
Oliver> don`t understand why a 16-bit gamma upload to the scanner is
Oliver> byte-order independent and a 16-bit download from the
Oliver> backend to the frontend is must take care of the
Oliver> byte-order/transform it.
Let me try to explain better: most backends do NOT need to worry about
byte-order---they can simply assume that the image data is in their
native byte-order. The only exception is the "net" backend since if
it runs on a host whose byte-order differs from that of the server,
then the "net" backend needs to adjust the byte order.
For control data (such as gamma-tables), the convention is that the
network protocol always uses big-endian (aka network byteorder) and
this is taken care of by the "wire" protocol (look at
sanei_code_bin.c, for example). The reason we don't use the same
approach for the image data is that image data tends to be much
bigger, so you want to be as efficient as possible. With a "receiver
makes right" approach where the server always sends data in its native
format, you only get the byte-swapping overhead when strictly
necessary (i.e., when there is an endianness mismatch). This is
particularly important given that most machines these days are
little-endian.
Oliver> Byt the way, I don`t think that it is good for efficency
Oliver> that that byte-order must be swapped twice sometimes:
Oliver> scanner-byte-order to backend-byte-order to
Oliver> frontend-byte-order.
Exactly. But for control data, the overhead tends to be small enough
not to warrant the extra complexity.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com