Return-Path: <schngrg@gmail.com>
Received: from inas029.isp.belgacom.be (localhost [127.0.0.1])
        by inav008.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k5CDxS8j008066
        for <joris.at.lebbeke@skynet.be>; Mon, 12 Jun 2006 15:59:29 +0200
        (envelope-from <schngrg@gmail.com>)
Received: from inmx015.isp.belgacom.be (inmx015.isp.belgacom.be [195.238.4.218])
        by inas029.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k5CDxN0E028872
        for <joris.at.lebbeke@skynet.be>; Mon, 12 Jun 2006 15:59:24 +0200
        (envelope-from <schngrg@gmail.com>)
Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205])
        by inmx015.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k5CDx9vl029011
        for <joris.at.lebbeke@skynet.be>; Mon, 12 Jun 2006 15:59:17 +0200
        (envelope-from <schngrg@gmail.com>)
Received: by nz-out-0102.google.com with SMTP id q3so1217846nzb
        for <joris.at.lebbeke@skynet.be>; Mon, 12 Jun 2006 06:59:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=DsHJLM5HFBiPa0j5XmU6XI5Ns50Hm5fORYJ1detKTdp7U068ciNuj/kbuiLldpDEjQK8kkcraB2fCWQfimQHmPC7jmWvVFG/77FG+m2K0t4IRcBizDY0fsKiU8eKFq20uAy2hRcMHXtvckpQ9Wwdpd/33JP5yvqiTjGN5JPX0sM=
Received: by 10.65.176.12 with SMTP id d12mr4634171qbp;
        Mon, 12 Jun 2006 06:59:16 -0700 (PDT)
Received: by 10.65.114.8 with HTTP; Mon, 12 Jun 2006 06:59:16 -0700 (PDT)
Message-ID: <b3530370606120659j51e91bb1nee0969cf706cdf74@mail.gmail.com>
Date: Mon, 12 Jun 2006 19:29:16 +0530
From: "Sachin Garg" <schngrg@gmail.com>
To: tiff@lists.maptools.org
Subject: Re: [Tiff] Editing a tiff image using libtiff
Cc: Joris <joris.at.lebbeke@skynet.be>
In-Reply-To: <000e01c68a31$081ce5e0$32c8f451@dfgrrxsknr4e>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <b3530370606070439k7575c44fgad29a361e12ba7a8@mail.gmail.com>
	 <000e01c68a31$081ce5e0$32c8f451@dfgrrxsknr4e>
X-UIDL: 000000000023ceae.0000179a
X-MSP-STORE: Mon, 12 Jun 2006 15:59:31 +0200
Status:   

On 6/7/06, Joris <joris.at.lebbeke@skynet.be> wrote:
> Sachin,
>
> Sachin Garg wrote:
> > I am coding an application where I want to do a minor edit in a tiff
> > image. The problem is that even a minor edit can change the compressed
> > image size, and this will mean that all the offsets everywhere to all
> > the tags/values after the compressed image data will have to updated.
> >
> > afaik, libtiff rewrites the entire tiff image with the directory at
> > the end. However in cases where a user might have structured a tiff
> > file as per his specific requirements, such restructuring for a minor
> > edit may be too much to ask.
> >
> > I will like to be able to do this minor image edit while maintaining
> > the existing tiff structure, but updating all the offsets seems an
> > overwhelming task. Any suggestions on how I should tackle this
> > situation?
>
> I'm not sure what you mean by 'restructuring' or 'have structured a
> tiff'...
>
> Are you refering to the order of the different data blocks? In that
> case, you're not talking about TIFF. There is no need for any specific
> order of data blocks in TIFF. Thus, you can hold on to any that you
> don't change in this 'minor edit' operation, and have the new IFD point
> to exactly those old locations. Any that do change, you can append to
> the file, or, if the new size does not exceed the old, write in the old
> location. Next, you can write an updated IFD, again, either appended to
> the file, taking care to update old offset at the end of previous IFD,
> or, if size of new IFD does not exceed old, you can overwrite the old
> IFD.
>
> For example, suppose your minor edit operation does not affect image
> size or anything, but merely changes a single tile. You can compute the
> new tile size by pre-compressing it, worst case. If it fits the old
> space, it fits, and the only thing that need updating is one entry in
> the TileByteCounts tag. If it doesn't fit, append it, and the updating
> is limited to one entry in the TileOffsets and one entry in the
> TileByteCounts tag. This tag value or these tag values, can be changed
> in place, since their size does not change. Thus, neither does the IFD
> itself change, and you can leave that as it is.
>
> Does this help? Or am I not understanding your question?
>
> As to how to do this with LibTiff... That's another issue. But you seem
> to indicate you're not using LibTiff anyway.
>

Thanks Joris, your understanding of the question is correct. My
primary concern is changed tile size. (Image size etc will stay the
same.)

Appending is a good option, but will waste space and it does changes
the order of blocks/tags.

My assumption here is that users might expect that a program doing
minor edits will not restructure the entire file. (Imagine a huge tiff
image where someone has saved the tiles in an order which minimize
seeking etc... like in pyramidal tiffs.) I could be wrong in assuming
that people might be structuring tiff images as per their
requirements, I myself haven't worked on such applications.

To maintain the order, I am just a bit overwhelmed by the complexity
of having to update offsets of the all tags/values after the changed
tile. Is it actually hard or is it just me? It will be really great if
this can be possible using libtiff.

Sachin Garg [India]
www.sachingarg.com | www.c10n.info
