2010.06.12 15:52 "Re: [Tiff] libtiff and IPTC tag", by Lee Howard

Andreas,

If you would please file this on Bugzilla that would help keep this issue on the to-do list. Attaching a proposed patch would help it get resolved sooner.

Thanks,

Lee.

I'm using libtiff 3.9.2. in SView5 (.NET version) - in parallel, for some special cases, I've got some additional custom TIFF parser included in the same codebase.

I've encountered again a TIFF image where libtiff gives the following error/warning (i.e. debug log output):

<long filename>: wrong data type 7 for "RichTIFFIPTC"; tag ignored

I would expect, that libtiff handles that case gracefully, i.e. under

http://www.awaresystems.be/imaging/tiff/tifftags/iptc.html (greetings to Joris van Damme - whenever I google for some

 tifftag, this is one of the first page hits... ;-)

it is written for that tag

        Type            UNDEFINED or BYTE

and there even is a statement included

        Often times, the datatype is incorrectly specified as LONG.

A required tag type fix from BYTE (1) to UNDEFINED (7) should not be a reason to reject this tag, IMHO (I have some doubts regarding interchangeability with LONG, but that is type 4, and as long as we just read bytes, there won't occur any endianess isssue for sure).

However in tif_dirinfo.c within TIFFFieldInfo it is defined that libtiff expects LONG for TIFFTAG_RICHTIFFIPTC (custom field)...

Other descriptions of this issue (via Google): http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=12872

http://www.google.com/support/forum/p/Picasa/thread?tid=43cace71df6d6150&hl=en http://forums.cgsociety.org/archive/index.php/t-769395.html

There also were some statements found, that the original RichTIFF spec defined it as BYTE.

***

For now I'll add a workaround using my internal parser.

For the future it would be good to either have libtiff being more error tolerant, or having some kind of "strict" vs. "sloppy" parsing (maybe there is such switch yet, and I overlooked it).

***

Sample image can be provided by email if needed.