2009.10.06 22:07 "[Tiff] SourceForge terms changes, heads up", by Bob Friesenhahn

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

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/