1994.09.19 15:26 "Re: TIFF Bit Ordering Versus Fill Order", by Sam Leffler

If the bit order is different than the host bit order then each byte of raw image data is bit-reversed before being interpreted by a decoder.

What is "the host bit order"? Graphics devices have a bit order, e.g. the MSB may be shown to the left or to the right of the LSB on your screen. But computers as such?

Host bit order is the native bit order of the host cpu. The bit order of any associated graphics device is irrelevant since the image data bit order must be understood in order to properly decode compressed data. Note that this bit order handling is internal to the library when encoded image data is present; it's only visible to a user when no compression is used.

It may make sense to set the bit order the same as the byte order, because then you may fill the data in as bytes, and later access them as 16, 32, or even 64 bits at a time.

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

But I would prefer that data are always delivered to the application in a standard way, preferably MSB to LSB within each byte, as this is the default in the spec.

There are many things that the library does not do in order to simplify its work and permit applications to optimize performance (e.g. some people would like to see an interface where data is returned as packed 8-bit RGBA pixels). If data is not compressed then it will always be returned to an application in the native bit and byte order. If data is compressed then the native byte order will be guaranteed (this was added "recently"). There is no mechanism that I know of to identify the bit order of decoded data in order to know whether or not it needs to be bit reversed prior to return to the application.

In practice I've not seen any complaints about data being unreadable given the existing behaviour of the library. Is this a general request or do you have a specific problem?

    Sam