AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
June 2007

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



Valid HTML 4.01!



Thread

2007.06.14 12:37 "Hierarchic structure in TIFFs?", by Reinhard Mayr Aka Czerwinski
2007.06.14 14:04 "Re: Hierarchic structure in TIFFs?", by Joris Van Damme
2007.06.15 10:38 "Re: Hierarchic structure in TIFFs?", by Reinhard Mayr Aka Czerwinski

2007.06.15 10:38 "Re: Hierarchic structure in TIFFs?", by Reinhard Mayr Aka Czerwinski

Joris,

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