AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2006.01.01 16:57 "Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.01 18:02 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.01 18:50 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.01 21:13 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.02 16:08 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.03 00:27 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Jay Berkenbilt
2006.01.03 02:31 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.04 13:23 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Andrey Kiselev
2006.01.04 16:18 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.07 02:59 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Jay Berkenbilt

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

> > 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/