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.19 22:46 "Re: Now that you mention bit order...", by Sam Leffler
To: tiff@sgi.sgi.com
Subject: Now that you mention bit order...
Cc: Craig Jackson <CRAIGJ@epub.ziff.com>
Date: Mon, 19 Sep 1994 12:34:25 CDT
From: Craig Jackson <CRAIGJ@epub.ziff.com>
Actually, the desirable "host" bit order depends on the application.
I would suggest that there is no natural bit order in any system implementing
C, because bits are not addressable in C.
Huh? The issue is that if I think I know what (byte & 0x1) should be
then I'll want each byte of decoded data to be in an appropriate bit
order for my application--irrespective of how the data was stored in
the TIFF.
However, there are times when a MSB-to-LSB order is convenient for
processing, especially on big-endian machines. There are other times
when a LSB-to-MSB order is more convenient. These cases may be more
frequent on little-endian machines, but not restricted to them.
Would it be possible to have this be a settable parameter, without
causing too much of a performance hit?
The only issue is what to do with uncompressed image data that has
been written with a FillOrder tag whose value is opposite to some
expected bit order. I say this because compressed data must have the
bit order corrected prior to decoding or the decoder must be capable
of handling data whose FillOrder is opposite to an expected value.
I'll think about this request. This is getting dangerously close to
the "let's have the library do data formatting and unformatting" rathole
that I've tried very hard to avoid... On the other hand, I'm sensitive
to apps having to undo something the library did just 'cuz there's no
way to disable it--this is the sort of problem that makes folks avoid
using existing software.
Sam