AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.09.16 04:17 "TIFF Bit Ordering Versus Fill Order", by John M Davison
[...]
1994.09.19 11:48 "Re: TIFF Bit Ordering Versus Fill Order", by Niles Ritter
1994.09.19 22:48 "Re: TIFF Bit Ordering Versus Fill Order", by Sam Leffler
1994.09.20 00:03 "Re: TIFF Bit Ordering Versus Fill Order", by Joe Moss
1994.09.20 07:00 "Re: TIFF Bit Ordering Versus Fill Order", by Fredrik Lundh
[...]

1994.09.19 22:48 "Re: TIFF Bit Ordering Versus Fill Order", by Sam Leffler

Bit order and byte order are not necessarily related. I have experience working with devices that had/used byte order different from bit order.

What sort of devices?

I noticed that the libtiff code makes a comment to the effect, "How can bit-order be determined at runtime?" Are we talking here about the host CPU or an independent display device of some sort? If the latter, then it is hopeless for libtiff to try to determine "bit-order" at runtime.

Host CPU.

Byte order is naturally defined by the addressing mechanism, but bits are not addressed directly. However, a possible way to define host bit order would be to use the C bit-field struct operations. As an experiment, I compiled and ran the following code on an SGI, HP, Sun, Macintosh, VAX/VMS, Ultrix and Alpha OS (Sorry, couldn't find anyone who uses PC's around here -- could someone run this on a PC and report back?):

#include <stdio.h>

struct HighLowBits {
     unsigned int highbit:  1;
     unsigned int lowbits:  7;
};

I think this may do the trick. I'll have to verify it on a PC.

        Sam