Return-Path: <tiff-bounces@lists.maptools.org>
Received: from mailgate106.isp.belgacom.be (mailgate106.isp.belgacom.be [195.238.6.87])
        by inmx008.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id l5EEOTcP012237
        for <joris.at.lebbeke@skynet.be>; Thu, 14 Jun 2007 16:24:30 +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; 14 Jun 2007 16:24:29 +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 l5EE5YOU009381;
	Thu, 14 Jun 2007 10:08:51 -0400
Received: from outmx008.isp.belgacom.be (outmx008.isp.belgacom.be
	[195.238.5.235])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l5EE4cw7009349
	for <tiff@lists.maptools.org>; Thu, 14 Jun 2007 10:04:39 -0400
Received: from outmx008.isp.belgacom.be (localhost [127.0.0.1])
	by outmx008.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with ESMTP id l5EE4bff024470
	for <tiff@lists.maptools.org>; Thu, 14 Jun 2007 16:04:37 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from AWareCore2Duo (53.189-245-81.adsl-dyn.isp.belgacom.be
	[81.245.189.53])
	by outmx008.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with SMTP id l5EE4Wao024431; Thu, 14 Jun 2007 16:04:32 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <000a01c7ae8c$ed18fa00$0201a8c0@AWareCore2Duo>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Reinhard Mayr aka Czerwinski" <czerwinski1977@gmx.net>,
        <tiff@lists.maptools.org>
References: <20070614123711.287810@gmx.net>
Subject: Re: [Tiff] Hierarchic structure in TIFFs?
Date: Thu, 14 Jun 2007 16:04:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
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.00002419
X-MSP-STORE: Thu, 14 Jun 2007 16:24:31 +0200
Status: RO

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

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
