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

2007.06.15 10:38 "Re: [Tiff] Hierarchic structure in TIFFs?", by Reinhard Mayr aka Czerwinski


thank you for this comprehensive elaboration of the topic!

I looked up the TIFF specs and that is where I took the term "DirectoryEntry" from. In short: The header points to IFD0 (first IFD). The IFDs are organized in a single linked list. Each IFD contains an array of directory entries.

As far as I understood it, the directory entries one IFD refer to one image and its accompanying tags.

What I am actually interested in is: Is it possible (... well, and also reasonable) to create nested IFDs (or maybe I should call the nested SubFiles)? Or is the only possibility a sequence of images by the concatenation of IFDs?



-------- Original-Nachricht --------
Datum: Thu, 14 Jun 2007 16:04:25 +0200
Von: "Joris" <joris.at.lebbeke@skynet.be>

An: "Reinhard Mayr aka Czerwinski" <czerwinski1977@gmx.net>, tiff@lists.maptools.org Betreff: Re: [Tiff] Hierarchic structure in TIFFs?

> Reinhard,
> Reinhard Mayr aka Czerwinski wrote:
> > 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.

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser