AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2006

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



Valid HTML 4.01!



Thread

2006.01.04 18:26 "Endian Issue in Tiff codecs", by <cibby.cherian@wipro.com>
2006.01.04 18:54 "Re: Endian Issue in Tiff codecs", by Bob Friesenhahn

2006.01.04 18:54 "Re: 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/