2006.01.04 18:26 "[Tiff] Endian Issue in Tiff codecs", by

2006.01.04 18:54 "Re: [Tiff] Endian Issue in Tiff codecs", by Bob Friesenhahn

On Wed, 4 Jan 2006 cibby.cherian@wipro.com wrote:

I am using a Tiff codec in which I read the tiff files using the

following function "_psTIFF = TIFFOpen( strfilename.c_str(), "r" );".

to instatiate a tiff structure.
I would like to know in what byte order does the "TIFFOpen" function
return the tiff file in this case. I have mentioned only "r" in the mode
type.

Libtiff uses a scheme in which bits-per-sample of 8/16/24/32/64 are presented in native byte order, but other bits-per-sample value are presented in "natural" order (network order / big endian) as described in the TIFF specification. The same rules are observed when a strip or tile is written. So libtiff is handling byte ordering for you.

In both the above cases I am not reading or writting any byte order

fields, nor am I doing any byte releated manipulations. In any case, I
require to know about the byte order nature since I am aiming at having
a codec which is platform independant and would work fine on both a big
endian as well as a little endian system. So please do let me know as to
the nature in which the libtiff library read\write data to\from a tiff
file.

Been there, done that. In my case I found it easiest to always swap data into network byte order since I wanted to support bits-per-sample values other than a multiple of 8 bits. Unfortunately, there is a performance hit with this approach. You can also use the approach where bits-per-sample of 8/16/32/64 are handled as an array of native words of that size and anything outside of that is handled by bit-parsers in network byte order. Note that 24-bits is a special case since there is no native word to cover it, and libtiff started swapping it to native order (whatever that means for 24-bits) only recently.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/