2012.11.24 00:46 "Re: [Tiff] help writing thumbnails to TIFF file?", by Joris Van Damme
2012/11/24 Paul Heckbert <email@example.com>:
You shouldn't be using this.
If I remember correctly, at one time (a very long time ago) Pixar was writing huge TIFF files. They wanted consumers of such a file to be able to start making sense of the file, even before the producer of the file was fully finished. To accomplish this, they added this TIFFCheckpointDirectory. Its function is essentially, writing an unfinished IFD (unfinished in the sense that some strip/tiles are not written yet and their offsets and lengths will be 0), in an unfinished TIFF, linking it up, enabling consumers to start consuming, whilst the producer can go on producing. I don't remember how they proceded next... was the 'temporary' IFD in-place overriden, afterwards, or were new temps and the final version appended to the file whilst the pointers to the IFD got updated? Don't remember.
It's a hack that suited them fine. It's unlikely it'll ever suit you or anyone else. TIFFCheckpointDirectory is to LibTiff, like Stonehenge is to the real world... Everybody can tell that clearly at one point it did have some mysterious function. And that's why nobody gets rid of it. But you should not actually be using it.
If you need control over the order of the data blocks in TIFF, you're missing a vital point. TIFF does not define such a fixed order. There's very good reason for that. The order of things, is the order the encoder library feels comfortable with, given the circumstances. Any subsequent editing of the TIFF may confuse order of things further, by appending some overrides for tag values for example, linking to them from within a pre-existing IFD somewhere in the file, etc...
Things are quite different if you're after a semantic order, instead of a data order inside the file. You can of course have an IFD that is linked to be the first IFD in the list (even if it's written near the end of the file), and links to a subsequent IFD in the list (that might be written near the start of the file). That is legit. These IFDs, to applications other then your own, bear no meaningfull relationship other then the fact that they're included in the same file. Hence, you could say, these IFDs are pages in a multi-page file.
If you want to encode meaningfull relationships other then 'these are images and someone somewhere had some reason to put them in the same file', for example the relationship between a full-size image IFD and its thumbnail IFD, you need to use the full IFD tree, not just the top-level list. There's a tag for this, SubIFDs tag. This tag bears a secondary-level list of images that are alternatives of the main linking image (they may have other color spaces, other color depths, or most often other dimensions). It's most usefull if you include in the top-level list the IFD of the image you want 'naive' applications to view. Other relationships might exist, like for example the relationship between a composed image IFD and its composition layers, but there's no specification for it, you'd have to use your own tag to define this exactly like the SubIFDs tag.
Joris Van Damme