Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx016.isp.belgacom.be (inmx016.isp.belgacom.be [195.238.2.219])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j0LITQ4a014656
        for <joris.at.lebbeke@skynet.be>; Fri, 21 Jan 2005 19:29:26 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx016.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j0LITFbj026288
        for <joris.at.lebbeke@skynet.be>; Fri, 21 Jan 2005 19:29:18 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id D33BC5D9917; Fri, 21 Jan 2005 13:28:55 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206])
	by xserve.flids.com (Postfix) with ESMTP id 3D9375D98F1
	for <tiff@remotesensing.org>; Fri, 21 Jan 2005 13:28:53 -0500 (EST)
Received: by rproxy.gmail.com with SMTP id y7so130300rne
	for <tiff@remotesensing.org>; Fri, 21 Jan 2005 10:28:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
	b=c6R16pAhiL24PFvbTcc/VBsti2jzuHMvr5Cd2c2blkkL6hhTQ2REWjH8aPcaPIJ/xv0Gw8L3HgSSGWr8nRCpAdtJoOqiKo4M5M8FWSx+yojsVuvwbJ4VleObchnBxu4aI3qXgln0OugwIED047m3OjU0SDiIA1RJzxO+iV5pdhM=
Received: by 10.38.99.43 with SMTP id w43mr176153rnb;
	Fri, 21 Jan 2005 10:28:52 -0800 (PST)
Received: from ?192.168.1.10? ([80.119.96.208])
	by smtp.gmail.com with ESMTP id 70sm3905rnc.2005.01.21.10.28.51;
	Fri, 21 Jan 2005 10:28:52 -0800 (PST)
Message-ID: <41F149F4.4010902@gmail.com>
Date: Fri, 21 Jan 2005 19:29:08 +0100
From: Antoine <melser.anton@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041227)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tiff@remotesensing.org
Subject: Re: [Tiff] deleting tags!
References: <41F00FAD.5020403@gmail.com>	<931f8ea905012107145488e3b7@mail.gmail.com>	<6.0.0.22.1.20050121101926.027ea318@pop.earthlink.net>
	<931f8ea9050121094248605294@mail.gmail.com>
In-Reply-To: <931f8ea9050121094248605294@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: f3f67c5e8dd217aaa8eb627de9a003b7

Frank Warmerdam wrote:
> On Fri, 21 Jan 2005 10:20:53 -0500, Chris Losinger
> <losinger@earthlink.net> wrote:
> 
>>At 10:14 AM 1/21/2005, Frank Warmerdam wrote:
>>
>>>I'm not aware of any way of clearing a tag completely from the
>>>directory either.  In fact, "in place" update of a TIFF file on disk is
>>>still a relatively experimental area.  In the past before in-place update
>>>there was never a compelling need to delete tags from an in memory
>>>directory since you could update a file on disk (other than appending
>>>new images).
>>>...
>>>The more conventional approach though is to copy the file you
>>>want to change to a new file, and just avoid copying anything you
>>>don't want in the new file.
>>
>>         wouldn't blind copying break tag data offsets ?
> 
> 
> Chris,
> 
> Sorry, I wasn't clear.  I meant copying the way that tiffcp copies, tag
> by tag with "structural tags" handled by libtiff.   So for instance
> Antoine could hack a version of tiffcp that did not copy the "target"
> tag.   But tiffcp can be lossy in various ways so that isn't necessarily
> a great solution.
> 
> Best regards,
> 

Hi again, and thanks for your suggestions. The thing is that the 
(potential, we haven't got the contract yet) client needs the tiff files 
to be in a particular format - TIFF ATA v5 (2100), and our scanning 
software (drivers?) seems to want to produce a tag or two that are not 
allowed in this version. It may just be possible to tweak at that end, I 
haven't investigated fully there, but if not... does nobody else have a 
need to do this? It would be very strange if we were the only people to 
ever be asked to do something like this - what am I missing here?
I would like to get to know libtiff (and tiff in general) a bit better 
cos we do a *lot* of work with tiff files but my c is abysmal. Any 
pointers would be great.
Cheers
Antoine
ps. what exactly do we lose with tiffcp? I found one way of "deleting" a 
tag - tiffcp will fail to copy a tag if it has an illegal value for its 
value (or values, I think it was the number of values that it takes, or 
size of the value, I forget, anyway we had dateTimes that had 25 
whatevers and should only have 20, the tag was present before setting 
another tag, and absent after...)
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
