Return-Path: <Gerben@ZyLAB.COM>
Received: from inas021.isp.belgacom.be (localhost [127.0.0.1])
        by inav029.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k5E9AZhS020842
        for <joris.at.lebbeke@skynet.be>; Wed, 14 Jun 2006 11:10:36 +0200
        (envelope-from <Gerben@ZyLAB.COM>)
Received: from inmx017.isp.belgacom.be (inmx017.isp.belgacom.be [195.238.4.129])
        by inas021.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k5E9AXvx015443
        for <joris.at.lebbeke@skynet.be>; Wed, 14 Jun 2006 11:10:34 +0200
        (envelope-from <Gerben@ZyLAB.COM>)
Received: from zynlfw01.zylab.com (mx.zylab.com [194.178.9.130])
        by inmx017.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k5E9ATCQ014117
        for <joris.at.lebbeke@skynet.be>; Wed, 14 Jun 2006 11:10:29 +0200
        (envelope-from <Gerben@ZyLAB.COM>)
Received: from zynlms01.ZyLAB.WAN (zynlms01.zylab.wan [192.168.1.10])
	by zynlfw01.zylab.com (Postfix) with ESMTP id 20E73206;
	Wed, 14 Jun 2006 11:03:19 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Re: [Tiff] Editing a tiff image using libtiff
Date: Wed, 14 Jun 2006 11:08:07 +0200
Message-ID: <FC840EC0BF7BFA45A0F94548AF36920DABF2B6@zynlms01.ZyLAB.WAN>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tiff] Editing a tiff image using libtiff
Thread-Index: AcaPBdq3Lz7vhmV0SkOuGF/JVRQwzQAigfKw
From: "Gerben Vos" <Gerben@ZyLAB.COM>
To: <tiff@lists.maptools.org>
Cc: "Joris" <joris.at.lebbeke@skynet.be>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by inav029.isp.belgacom.be id k5E9AZhS020842
X-UIDL: 000000000023ceae.000017b4
X-MSP-STORE: Wed, 14 Jun 2006 11:10:37 +0200
Status:   

> If ever a TIFF with memory-management data were to be designed, the data better
> accompanies each data block.

The easiest way is of course to make a single-linked list: put a pointer to the first free memory block in bytes 8-11. Every free memory block then contains a pointer to the next block in bytes 0-3 of the block, and its own length in bytes 4-7. End of list is indicated by a zero pointer. Blocks of less than 8 bytes can't be linked and are lost. In BigTiff, the pointers and lengths would become 8 bytes, and the minimum reclaimable block size 16 bytes.

Two problems: how to indicate the fact that we have a free block list (a magic number in bytes 12-15?), and non-free-block-list-aware programs that edit a TIFF will destroy it, so implementations using the list should be extremely robust (at the very least, check for pointers outside the file, and that you're not overwriting IFDs). The second problem probably makes this idea too complicated to implement; it may be easier for applications/libraries to just calculate the free spaces from the IFDs.

Sorry, just thinking aloud... :-)

					Gerben.

