[sane-devel] network endian issues

Henning Meier-Geinitz henning@meier-geinitz.de
Fri, 21 Sep 2001 13:39:58 +0200


On Thu, Sep 20, 2001 at 02:07:04PM -0400, wls@astro.umd.edu wrote:
> I'm not sure if this has been mentioned before or even if I may have reported
> it before: has the network protocol been thought out so that network scanning
> will work if the backend and frontend machines have different byte order?


> It does not appear to be so.

If this weren't true, you wouldn't be able to scan over the network at
all. Think about integer values transferred over the net.

The standard states (3.2.1 Image Transmission):

| Conceptually, each frame is transmitted a byte at a time.  Each byte
| may contain 8 sample values (for an image bit depth of 1), one full
| sample value (for an image bit depth of 8), or a partial sample value
| (for an image bit depth of 16 or bigger).  In the latter case, the
| bytes of each sample value are transmitted in the machine's native
| byte order.

| Backend Implementation Note
| A network-based meta backend will have to ensure that the byte order
| in image data is adjusted appropriately if necessary. For example,
| when the meta backend attaches to the server proxy, the proxy may
| inform the backend of the server's byte order.  The backend can
| then apply the adjustment if necessary.  In essence, this implements a
| `receiver-makes-right'' approach.

> When a preview is requested with xsane at 12 bits the result looks garbled,
> like the bytes have been swapped.  A preview at 8 bits looks fine as does a 12
> or 8 bit preview with xsane running on another sparc.  xscanimage didn't allow
> a 12 bit preview but a scan at 12 bits (frontend running on Linux Intel
> computer) came out looking like its bytes were swapped.

That's a bug in saned.c/net.c and already mentioned in the TODO list.
However, nobody has fixed it until now.

Thanks for pointing out that problem.