2005.12.12 22:19 "[Tiff] Writing EXIF data?", by Paul J. Lucas

2006.01.03 02:31 "Re: [Tiff] Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn

On Mon, 2 Jan 2006, Jay Berkenbilt wrote:

A bit of testing shows that previously the third parameter of TIFFGetField() was of type uint32 when retrieving TIFFTAG_ICCPROFILE, TIFFTAG_PHOTOSHOP, TIFFTAG_RICHTIFFIPTC, TIFFTAG_XMLPACKET, but in 3.8.0 the size is a uint16. Unfortunately this interface is not fully defined by a header file since it is based on a variable argument list. Libtiff 3.8.0 is *not* binary compatible with previous releases.

For such a small change, I would vote for reverting it rather than introducing a binary incompatibility. Library ABI changes are a big

I think that this qualifies as a "bug" due to rewriting the supportive code. It was not an intentional ABI change. Since headers are not involved, it does not impact software unless the software uses the tags. Unfortunately, depending on endian order, default variable values, and tag size, the content of the tags may be unexpectedly corrupted. So we may encounter TIFF files with ICC color profiles clipped to 64K, or expanded to hundreds of megabytes.

deal for distributions, so it would be shame to have to have one for such a small change. I doubt many debian applications or libraries use these tags, but it's certainly possible that some do and likely that some debian users use them in their own programs. I was hoping that the next ABI change would coincide with a library with release

that used full symbol versioning and took advantage of one big chance to break everything that needs breaking all at once.

Professional level software certainly needs to support these tags. They are necessary in order to interoperate with industry-standard software like Photoshop and to support ICC color profiles. Certainly ImageMagick, GraphicsMagick, and CinePaint are using these tags.

Is there a chance that this change will be reverted, or are we stuck with it?

Presumably it will be fixed in the next release.

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