Return-Path: <tiff-bounces@lists.maptools.org>
Received: from mailgate001.isp.belgacom.be (mailgate001.isp.belgacom.be [195.238.6.100])
        by inmx019.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id l5FAmAN7016740
        for <joris.at.lebbeke@skynet.be>; Fri, 15 Jun 2007 12:48:10 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 15 Jun 2007 12:48:09 +0200
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l5FAdIOo028224;
	Fri, 15 Jun 2007 06:39:31 -0400
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by duke.maptools.org (8.12.11/8.12.10) with SMTP id l5FActh5028219
	for <tiff@lists.maptools.org>; Fri, 15 Jun 2007 06:38:56 -0400
Received: (qmail 26966 invoked by uid 0); 15 Jun 2007 10:38:55 -0000
Received: from 80.243.168.94 by www002.gmx.net with HTTP;
	Fri, 15 Jun 2007 12:38:55 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 15 Jun 2007 12:38:55 +0200
From: "Reinhard Mayr aka Czerwinski" <czerwinski1977@gmx.net>
In-Reply-To: <000a01c7ae8c$ed18fa00$0201a8c0@AWareCore2Duo>
Message-ID: <20070615103855.276640@gmx.net>
MIME-Version: 1.0
References: <20070614123711.287810@gmx.net>
	<000a01c7ae8c$ed18fa00$0201a8c0@AWareCore2Duo>
Subject: Re: [Tiff] Hierarchic structure in TIFFs?
To: "Joris" <joris.at.lebbeke@skynet.be>, tiff@lists.maptools.org
X-Authenticated: #28251939
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX18rGN82avQr2BhtO8yggQxRMDiko6YjUEgWy3g315
	DUCN8wDLZZxzNgUb1zL0Om1+CBXxQQu1aMeA== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: WwUXB34YfW47bBlN2GRo3jxudmllcgVD
Cc: 
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00002426
X-MSP-STORE: Fri, 15 Jun 2007 12:48:11 +0200
Status: RO

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
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
