| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2007.06.15 10:38 "Re: Hierarchic structure in TIFFs?", by Reinhard Mayr Aka CzerwinskiJoris, 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? Cheers, Cz. -------- 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. > > > 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 -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser |
|||||||