2007.06.14 09:52 "[Tiff] Read tiff in pf1bit", by Philip Chan

2007.06.14 14:04 "Re: [Tiff] Hierarchic structure in TIFFs?", by Joris Van Damme


does the TIFF specification include hierarchical multi-page files like

 * header
  * IFD1

   * DirectoryEntry1 -> IFD
    * DirecotryEntry1.1 -> Image1
    * DirecotryEntry1.2 -> Image2
   * DirectoryEntry2 -> IFD
    * DirecotryEntry2.1 -> Image3
    * DirecotryEntry2.2 -> Image4
    * DirecotryEntry2.3 -> Image5
  * (next IFD) IFD2
   * DirectoryEntry3 -> IFD
    * DirecotryEntry3.1 -> Image1
    * DirecotryEntry3.2 -> Image2
    * DirecotryEntry3.3 -> Image3
    * DirecotryEntry3.4 -> Image4

   * DirectoryEntry4 -> Image5

 Thanks in advance for all hints & pointers!

I'm not sure what you mean by DirectoryEntry. You're probably refering to what we like to call 'tag' or 'field'. Tags can have all sorts of meaning. Like, one in particular gives information about what color family the image is encoded in, it is called the PhotometricInterpretation tag. For a good overview of the different 'DirectoryEntry' types and their meaning, see http://www.awaresystems.be/imaging/tiff/tifftags.html.

This said, there are tags that can point to child IFDs. The meaning of the child IFD depends on the particular tag that does the pointing. For instance, the EXIF tag points to an EXIF IFD. The SubIFDs tag points to image IFDs that are equivalents of the base image, but have different sizes.

So, apart from a few side remarks, the notion of 'hierarchical multi-page files' is indeed a correct notion supported by TIFF.

The main issue is, however, not storage, but interpretation. How are we supposed to interpret trees of images? What should be displayed, in what order, by a naive viewer that isn't able to read the thoughts of the writer? The de facto accepted interpretation, these days, is that different image IFDs in the main linked list represent different pages of a multi-page document. SubIFD branches linked to from an individual image IFD, represent thumbnails or otherwise scaled equivalents of that individual image. There is no accepted way to encode other image relationships, like different layers of a single composed image for example. Not yet, anyway, but I'd be interested to come up with a proposal in this area sooner or later.

One thing that complicates matters quite a bit, is that this de facto accepted modern standard is different from yesterday's standard. Yesterday, different downsized equivalents of an image IFD could be linked in the main linked list, and marked as such with SubFiletype or NewSubfileType tags (http://www.awaresystems.be/imaging/tiff/tifftags/subfiletype.html and http://www.awaresystems.be/imaging/tiff/tifftags/newsubfiletype.html). This old way of storing things is largely abandoned, but some still use it and there's always old file around too. It wasn't a very good way, because readers needed to scan ahead in order to conclude they saw all about a 'page', and also because of the way page splitters and concatters and resorters and all, and users using those, contributed to the mess when they weren't very carefull.

There are also files around, in the wild, that encode an image in IFD0 (the first IFD in the main linked list), and EXIF info in IFD1 (the second IFD in the main linked list). There are also files around, in the wild, that have multiple IFDs in the main linked list, without SubFiletype or NewSubfileType tags, and upon visual inspection it turns out some are downsamples of the first image. There is simply no way to really interpret these usefully, programmatically. Let's hope there aren't many people left producing such files.

Best regards,

Joris Van Damme
Download your free TIFF tag viewer for windows here: