[sane-devel] 16 bits / color scanning

[m. allan noah]

actually, the wikipedia page says this:

Unfortunately it appears that the various implementations could not
agree on which byte order to use, and some connected the 16-bit
endianness to the pixel packing order.[5] In Netpbm, the de facto
standard implementation of the PNM formats, the most significant byte
is first.

Now, I don't take anything on wikipedia seriously, but it does point
out the problem. There is no standard either in PNM, or in SANE. So,
we would have to define that. Big endian is fine with me.

allan

2011/12/16 Kåre Särs <kare.sars at iki.fi>:
> Hello,
>
> On Thursday 15 December 2011 06:40:32 Stef wrote:
>> Le mercredi 14 décembre 2011 10:17:38 Kåre Särs a écrit :
>> > Hi,
>> >
>> > While testing the 16 bit features of Skanlite I noticed a problem with
>> > endianness. If I scan directly with epson2 on a x86 I get one byte
>> > order,
>> > but if I do a network scan through saned+epson2 running on a PowerPC I
>> > get the other order....
>> >
>> > Is there a workaround for this?
>>
>>       Hello,
>>
>>       does this byte inversion problem happen with any frontends ? Like
>> scanimage or xsane ?
> Yes xsane has the same problem.
>
>> How epson2 running directly on PPC does behave ?
> I run scanimage on the PPC and copied the resulting image to my PC, but this
> image also had the inversion problem. According to Wikipedia the 'Netpbm PPM
> "rawbits" image data' format should be platform independent... I have not
> tried to view it over ssh on my headless PPC yet.
>
>>       According to the SANE standard, the SANE_NET_START RPC sends the byte
>> order, which should allow to handle endianess issues.
>>
>
> Regards,
>   Kåre
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>             to sane-devel-request at lists.alioth.debian.org



-- 
"The truth is an offense, but not a sin"