LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
December 1996
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1996.12.13 18: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.