2006.01.01 18:50 "Re: [Tiff] Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
As another tidbit of information, a GraphicsMagick built against libtiff 3.8.0 using Visual C++ under Windows reports the correct tag size values. In that build environment, the libtiff headers are used directly from the libtiff build directory.
It appears that problem may be isolated to the header files formally installed using the Unix configure script. The installed headers include a "mini-configuration" which is supposed to supply just enough configuration information for the header files to work correctly. I did verify for a certainty that the correct libtiff headers are being used by the Unix build.
As a follow-up, I have now learned several interesting things regarding this issue.
Using GraphicsMagick with libtiff 3.7.3 on Intel produces correct values. After updating libtiff to 3.8.0 on Intel but not rebuilding GraphicsMagick (I verified that GM is using new libtiff) libtiff 3.8.0 on Intel still produces correct values. After rebuilding GM, wrong values are produced.
When operating correctly the tag size is reported as 5916 bytes whereas on SPARC it is reported as 387738624 bytes. These values actually have a relationship as can be seen from the hex equivalents:
5916 ==> 0x171C
387738624 ==> 0x171C6C00 (reported by GM on SPARC)
538973980 ==> 0x2020171C (reported by GM on Intel)
So it can be seen that the 0x171C value is embedded in the SPARC and Intel results, but the 16-bit word positioning is exchanged. It seems like a 16-bit word is being written into the space of a 32-bit type but the compiler thinks that the storage is a 16-bit type.
Given that libtiff returned correct values to GraphicsMagick for a GraphicsMagick built against older libtiff headers, it seems likely that the problem is due to a mis-match in the installed libtiff headers.
On Sun, 1 Jan 2006, Bob Friesenhahn wrote:
> Using libtiff 3.8.0, I noticed that GraphicsMagick was extremely slow (on > a big-endian system) at loading some files written by Photoshop CS2. The
>> TIFF files were downloaded from
These files contain Photoshop and XMP profiles.
When the size (length is type 'uint32') is obtained via
The length values reported are huge sizes like 387738624 or 979463168.
> Somehow tiffinfo on the same system gets the length correct. For example,
it reports that the Photoshop data is 5696 bytes.
On a little-endian system using libtiff 3.7.3 the sizes are reported
> correctly to GraphicsMagick.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/