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 17:34 "Now that you mention bit order...", by Craig Jackson
1994.09.19 19:04 "Bit order revisited ...", by Scott Wagner
1994.09.19 22:46 "Re: Now that you mention bit order...", by Sam Leffler
1994.09.20 13:25 "RE: Now that you mention bit order...", by Scott Wagner
1994.09.22 22:50 "Re: Now that you mention bit order...", by John M Davison
[...]

1994.09.20 13:25 "RE: Now that you mention bit order...", by Scott Wagner

OK! Enough! This reminds me of the raging bit order debate that consumed all attention at my company about 3 months ago (when we got our hands on an imager that expected LSB-to-MSB bit order and all hell broke loose).

First, I expect that most images in an accepted image file format (TIFF [unless FillOrder is explicitly defined and set to 2], GIF, PICT, BMP, EPS, ...) will be MSB-to-LSB. The exception seems to be raw FAX documents, which seem to like LSB-to-MSB order because that is the order in which UARTs (that's the functional block or chip that does serial <-> parallel conversion) on FAX machines work. Note that the Windows BMP is MSB-to-LSB, even though the accursed 80x86 on which Windows was originally designed is little endian and the PC's response to Craig Jackson's test program is

This is a LittleEndian machine
Byte with highbit set has value 1

Now it is fairly easy, albeit time consuming and irritating, to change bit order. Each byte of incoming data (ugh!) gets run through a 256-byte array that looks like:

unsigned char const swapit[256] = {0x00,0x80,0x40,0xc0,0x20,..., 0xef,0xff};

output = swapit[input];

And that, IMHO, is the bit-order confusion story in a nutshell.

Scott Wagner (wagner@itek.com)
Senior Engineer
Itek Graphix
Rochester, NY USA