1994.09.22 23:49 "Re: Now that you mention bit order...", by Sam Leffler

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

Mr. Wagner left out one fact, namely that the notion of "native machine bit order", as it exists in Sam Leffler's TIFF interface software, is nonsensical.

While a "bit order" issue certainly does come up when dealing with rendering/scanning systems that erroneously permute bits, the handling of this erroneous behavior is the responsibility of the associated drivers, not of any device-independent TIFF interface software (such as what Leffler has written).

Thus, the notion of "native machine bit order" should be expunged from Sam Leffler's TIFF interface software. Leffler's software has no business whatsoever worrying about rendering/scanning device "bit order".

Come on folks, enough of this crap already. As I've repeatedly explained; the library handles the FillOrder tag as necessary for image data that's encoded. For data that is uncompressed it does its best to return the data to the application program in the appropriate bit+byte order for the application to directly interpret sample values (consider the case where IEEE floating point samples are to be exchanged between hosts with CPUs that use different bit+byte order). The library has done this for many years and I've yet to receive a single solid example of what it's doing wrong. I intend to provide a mechanism whereby the library's behaviour for uncompressed data can be defeated so that an application does not have to undo work in order to make use of the data. This should close the one obvious loophole in the API.

If you or someone else has a specific example where the library does something wrong, please send me mail directly. Please do not send me hypothetical examples, send me something real.

        Sam