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
October 2009

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

2009.10.07 19:25 "Wrong Native Bit Order on Intel x86_64", by Eskandar Ensafi
2009.10.07 19:59 "Re: Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn
2009.10.07 20:11 "Re: Wrong Native Bit Order on Intel x86_64", by Eskandar Ensafi
2009.10.07 20:24 "Re: Wrong Native Bit Order on Intel x86_64", by Toby Thain
2009.10.07 20:28 "Re: Wrong Native Bit Order on Intel x86_64", by Edward Lam
2009.10.07 21:26 "Re: Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn
2009.10.07 20:47 "Re: Wrong Native Bit Order on Intel x86_64", by Igor Skochinsky
2009.10.07 21:10 "Re: Wrong Native Bit Order on Intel x86_64", by Toby Thain
2009.10.07 20:17 "Re: Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn
2009.10.07 20:40 "Re: Wrong Native Bit Order on Intel x86_64", by Edward Lam
2009.10.07 21:43 "Re: Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn

2009.10.07 21:26 "Re: Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn

On Wed, 7 Oct 2009, Eskandar Ensafi wrote:
>
> Hopefully, this tag is not being used by most applications because it
> would mean that when you write an image on a 64-bit system and try to view
> it on a 32-bit system, or vice versa, then the bits will be reversed and
> the image data will become rubbish.  I'm not so sure if "bit order" really
> matters, does it?

Of course bit order really does matter. If libtiff encounters a TIFF 
file written in a different order then it needs to reverse the order 
of the bits while reading.  If TIFF is requested to write output in a 
different order than the native order, then it needs to reverse the 
order of the bits while writing.  It does this via a TIFFReverseBits() 
function in libtiff/tif_swab.c.  This is important for FAX 
compression.

Here is where it is used:

   File        Function              Line
1 tif_jbig.c  JBIGDecode             86 TIFFReverseBits(tif->tif_rawdata,
tif->tif_rawdatasize);
2 tif_jbig.c  JBIGOutputBie         175 TIFFReverseBits(buffer, len);
3 tif_read.c  TIFFFillStrip         354 TIFFReverseBits(tif->tif_rawdata,
bytecount);
4 tif_read.c  TIFFFillTile          577 TIFFReverseBits(tif->tif_rawdata,
bytecount);
5 tif_write.c TIFFWriteEncodedStrip 249 TIFFReverseBits(tif->tif_rawdata,
tif->tif_rawcc);
6 tif_write.c TIFFWriteEncodedTile  404 TIFFReverseBits((unsigned char
*)tif->tif_rawdata, tif->tif_rawcc);
7 tif_write.c TIFFFlushData1        687 TIFFReverseBits((unsigned char
*)tif->tif_rawdata,

Some CPUs use a different fill order than others just like some CPUs 
are big endian and other CPUs are little endian.

It seems pretty mysterious that it took three years for this issue to 
be discovered and reported so probably there is something I am not 
understanding.

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