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
