LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 1994
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
1994.09.22 23:49 "Re: Now that you mention bit order...", by Sam Leffler
To: tiff@sgi.sgi.com
Subject: Re: Now that you mention bit order...
Cc: wagner@itek.com
Date: Thu, 22 Sep 1994 17:50:54 CDT
From: John M Davison <davisonj@ecn.purdue.edu>
Scott Wagner (wagner@itek.com) writes:
>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