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 15:26 "Re: TIFF Bit Ordering Versus Fill Order", by Sam Leffler
To: tiff@sgi.sgi.com
Subject: Re: TIFF Bit Ordering Versus Fill Order
Cc: krs@kampsax.dk
Date: Mon, 19 Sep 1994 08:55:22 +0200
From: "Karsten Spang" <krs@kampsax.dk>
In message <9409161742.AA01599@oxford.chez.sgi.com> ,
Sam Leffler <sam@oxford.chez.sgi.com> writes:
> 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