Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx014.isp.belgacom.be (inmx014.isp.belgacom.be [195.238.2.217])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id iB6Mqmeb027826
        for <joris.at.lebbeke@skynet.be>; Mon, 6 Dec 2004 23:52:48 +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 inmx014.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id iB6MqTM5012396
        for <joris.at.lebbeke@skynet.be>; Mon, 6 Dec 2004 23:52:31 +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 E88F64DCD9F; Mon,  6 Dec 2004 17:52:10 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx005.isp.belgacom.be (outmx005.isp.belgacom.be
	[195.238.2.102])
	by xserve.flids.com (Postfix) with ESMTP id 8CA704DCD78
	for <tiff@remotesensing.org>; Mon,  6 Dec 2004 17:52:03 -0500 (EST)
Received: from outmx005.isp.belgacom.be (localhost [127.0.0.1])
	by outmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id iB6MppFD029463
	for <tiff@remotesensing.org>; Mon, 6 Dec 2004 23:51:52 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (198-163.245.81.adsl.skynet.be [81.245.163.198])
	by outmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id iB6MpnVe029446; Mon, 6 Dec 2004 23:51:49 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <001f01c4dbe6$402fec20$c6a3f551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Chris Losinger" <losinger@earthlink.net>,
        "Tiff mailing list" <tiff@remotesensing.org>,
        "Andrey Kiselev" <dron@ak4719.spb.edu>
References: <41AF59CD.3090603@rabien.com>
	<20041202183006.GA14794@ak4719.spb.edu>
Subject: Re: [Tiff] Having problems adding IPTC to a TIFF
Date: Mon, 6 Dec 2004 23:52:17 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Cc: 
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: 97bfbd484a875785d46a4c5ca051b909

> This problem should be fixed in CVS (i.e., in post-3.7.0 code). Please,
> try to fetch the most recent snapshot and test your code with it.

A while ago (http://www.asmail.be/msg0055489739.html), I mentioned that the IPTC
tag datatype, TIFF_LONG according to LibTiff code, was suspicious. Other sources
mentioned datatype TIFF_BYTE or TIFF_ASCII. Having in mind byte order issues, it
seemed strange that a tag could be defined as having either an 8bit or 32bit
datatype.

Thanks to Chris Losinger (Thanks, Chris!), I now have the data structure layout
of the IPTC data, which seemed not readily present in the specification. (Or
either I'm to stupid and/or lazy to wade through a lot of mystical stuff that is
not clearly preceded by data structures and such.) The data structure contains
byte values, word values and cardinal values that define a set of tags, each of
which has specific other data that can have any sort of structure. Thus, the
IPTC tag datatype should clearly be TIFF_UNDEFINED, or TIFF_BYTE which is
functionally the same.

I tested this newly acquired knowledge on some TIFFs. With some of them, it
makes perfect sense. Some others make sense only after unswapping the bytes, ie,
at some stage the data has incorrectly been byteswapped as if it were an array
of 32bit values which it is not. These others also typically have a too large
count. Clearly, these are written by LibTiff with a wrong datatype definition.

My questions are:
- Is the datatype corrected in this newer CVS version? Is that part of the
mentioned bugfix? If it is not, will you correct it so as to stop LibTiff
writing any more TIFFs with corrupted (!) IPTC data in the future?
- A quick and dirty method to see if IPTC tag data has been incorrectly
byteswapped, is testing the first byte. If it is not equal to 0x1C, then most
probably the fourth byte of the data is equal to 0x1C, and you need to unswap it
to recover the correct data. In that case, the tag count may be unreliable too,
so the reader needs to be build to read whatever it can up to the point where
the data stops making sense. Does such a robust reader that recovers from
LibTiff's data corruption seems sensible to you guys?

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@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
