2006.01.01 21:13 "Re: [Tiff] Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
To add even more information regarding this issue. I installed libtiff 3.7.3 and GM reported correct tag sizes both before recompiling with 3.7.3 and after. I installed libtiff 3.7.4 and GM reported correct tag sizes both before recompiling with 3.7.4 and after. I installed libtiff 3.8.0 and GM reported wrong tag sizes both before recompiling with 3.8.0 and after.
To summarize in the form of a matrix of header versions (vertical) vs library versions (horizontal):
headers/Lib 3.7.3 3.7.4 3.8.0
3.7.3 Works Works Works
3.7.4 Works Works Fails
3.8.0 Works Fails Fails
So the header sensitivity to the library problem was added in 3.7.4 but the failure does not occur until 3.8.0.
On Sun, 1 Jan 2006, Bob Friesenhahn wrote:
> 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.
> On Sun, 1 Jan 2006, Bob Friesenhahn wrote:
>> 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.
>>> Bob Friesenhahn
>> Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/