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
Thread
2006.01.01 18:02 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
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.
Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/