[sane-devel] sane-canon: Endian inverted data when scanning 48bbp raw mode pnm

[Henning Meier-Geinitz]

Hi,

On Tue, Dec 27, 2005 at 04:47:21PM +0100, Jean-Michel Vourgère wrote:
> On Tuesday 27 December 2005 14:32, Henning Meier-Geinitz wrote:
> > > Using imagemagick on the raw data give images with noise. Switching
> > > bytes before using imagemagick' convert works ok.
> > > The noise also appears in preview window when mode is raw, so the bug
> > > is probably in sane and not imagemagick.
> > Maybe the author of the backend uses a big endian machine :-)
> 
> It's probable :
> 
> I had a look at the source and the data is vonluntarily byte swicthed
> during output, due to little endian detection:

> #if !defined(WORDS_BIGENDIAN) line 1334 of sane-backends-1.0.17/frontend/scanimage.c
> 
> I tested: That code is run.

According to the SANE standard (3.2.1):  "the bytes of each sample
value are transmitted in the machine's native byte order". 

According to the pnm standard (ppm): "The most significant byte is
first". 

Therefore, on little endian machines the bytes received by scanimage
have to have little endian byte order and have to be swapped when
saving as pnm file. scanimage is correct.

> However, the data is allready byte-switched in the backend (canon-sane.c function read_fs2710 line 1790) with that comment:
>   /* We must receive 2 bytes per pixel and colour. In raw mode we
>      must swap the bytes (for compatibility with xsane) and pass
>      them both. (...) */
> That particuliar inversion is allways performed, no matter the platform "endianness".

At least in theory, it could be even more complicated. I didn't check
the canon backend, but for some scanners the endianess of the data
sent from the scanner to the host can be changed.

Anyway, the canon backend has to ensure that the data sent to the
frontend (any frontend, not only xsane), is in the same byte order as
the machine it is running on.

> Unless I missed something, I guess the byte switch in scanimage.c was
> only needed for some other backends. :(

No, this switch is needed for all SANE backends. If it weren't there,
your test with the test backend would not have succeded :-)

> But then wouldn't it make sense to byte-switch the data in the
> backends when needed rather than to do it twice when not needed?

As backends and frontends are completely independent from each other,
there had to be a definition of how to transport the data between
them. Using the machine's native byte order seems like a good choice.
As far as I remember, the choice for the 16 bit pnm format wasn't even
made when the SANE stndard was created (9 years ago).

> I'm done with old chimical films anyways (I definitly should have
> kept one for testing!), I hope that message and my previous
> workaround will help others.

I hope so, also, There is some work to be done by the canon backend
maintainer, I guess :-)

Bye,
  Henning