1996.12.13 11:08 "Re: fillorder of decoded strips", by Niles Ritter

So now I'm quite confused about how TIFFReadEncodedStrip works. From a few experiments I've done it seems the decoded data I get back from doing a TIFFReadEncodedStrip has a fill order of MSB2LSB. Should I assume it will always be like that as the TIFFOpen documentation implies? Is there someway to know for sure what the fill order is of what TIFFReadEncodedStrip returns?

To add to the confusion, I challenge anyone to define "native bit order" of a computer. You can try to insist that byte-order implies bit-order, but that is not a warranted assumption. The real question is, "ordered by what?" In a FAX machine, there is a natural hardware ordering, dictated by how the bit streams get stored in the online memory (which are presumably bytes). Section 11 of the TIFF spec discusses the hardware issues in detail. In the host cpu proper there is no natural addressing mechanism for bits (byte order is dictated by the natural ordering of address space).

You may try to insist that something like:

  struct mybits {
        int bit1 : 1;
        int bit2 : 1;
        ...
        int bit8 : 1;
 }

imposes a natural ordering, but the above structure is compiler dependent, not host-cpu-dependent.

The TIFF spec strongly discourages the use of LSB2MSB, regardless of the native byte-order of the cpu. I believe libtiff supports this by performing bit-swapping if and only if FillOrder=2 is explictly defined, for either byte-order. This means that you can always use (128,64,32,16,8,4,2,1) as your set of byte-masks to get the correct sequence of bits. Life is simpler that way.

And let's not even get into the 0=black/white issue...

--Niles.