LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 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.08.29 17:39 "Re: IPTC tag", by Joris Van Damme
Phil, Phil Harvey wrote: > Along the same lines, I also consider it a bug that IFD offsets are > written as long (value of 4). They should be written as IFD type > (value of 13), otherwise unknown IFD's can not be parsed. If we're > trying to fix historical bugs, maybe we could fix this as well. While > you may never have been stung by this bug, I have repeatedly because > of the non-standard TIFF-format information that my software has to > deal with. I wouldn't quite call this a 'bug' either... It's historical less then optimal file format design. When the issue became clear, the IFD datatype was introduced. But for the sacke of backward compatibility, we can only stronly recommend to use the IFD datatype for pointing to private IFDs, and not actually enforce it. What's in the name 'bug' though...? I do agree it is a major nuisance. Strictly and theoretically speaking, software shouldn't even touch a tag that it doesn't really 'know', so it should be aware anyway when a long datatype is used to point to a private IFD. But, for some applications, like TIFF page splitting or TIFF concat for example, and conversion between ClassicTIFF and BigTIFF, it is extremely tempting to deal with all tags, known and unknown, and this problem does come up and bites us in the face. There are other applications still, like TIFF garbadge collection (or defragmentation or whatever you wish to call it), that absolutely need to deal with all tags, known and unknow, and so this is a major problem. On the one hand we must indeed strongly recommend the IFD datatype for this purpose. On the other hand, we must use hacky heuristic techniques to discover the intent of long values of unknown tags, like building a total allocation map of a file following the top-level linked list and using all know tag values to discover lower-level lists, to next see if a long value of unknown tag could point to file space we haven't yet discovered any other use for. If so we need to peek at the data at that offset in order to statistically estimate the likelyhood it's an IFD. In other words, even though it can be made to be nearly always correct, it is very costly and guaranteed not quite perfect, and cannot work to discover seriously corrupt private IFDs for example. So, I do agree, even if the word 'bug' seems out of place to me. Perhaps, with the arrival of BigTIFF, people reconsidering parts of their codec for this purpose anyhow, and us speaking these issues whenever appropriate, things may evolve in the right direction. Thanks for helping me realize it was a mistake to ignore the fact some people will really need to continue writing IPTC data as longs (for now?). Best regards, Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html