Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.3.90])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id iB7MR6aD012093
        for <joris.at.lebbeke@skynet.be>; Tue, 7 Dec 2004 23:27:06 +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 inmx012.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id iB7MQm6B028029
        for <joris.at.lebbeke@skynet.be>; Tue, 7 Dec 2004 23:26:51 +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 DA35A4E2735; Tue,  7 Dec 2004 17:26:22 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from smtp4.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.27])
	by xserve.flids.com (Postfix) with ESMTP id 88FDE4E2725
	for <tiff@remotesensing.org>; Tue,  7 Dec 2004 17:26:21 -0500 (EST)
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf0409.wanadoo.fr (SMTP Server) with SMTP id 4934E1C00392;
	Tue,  7 Dec 2004 23:26:20 +0100 (CET)
Received: from [192.168.0.4] (AToulouse-152-1-35-88.w82-125.abo.wanadoo.fr
	[82.125.145.88])
	by mwinf0409.wanadoo.fr (SMTP Server) with ESMTP id BBE8F1C0038D;
	Tue,  7 Dec 2004 23:26:19 +0100 (CET)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 07 Dec 2004 23:26:18 +0100
Subject: Re: [Tiff] Having problems adding IPTC to a TIFF
From: Eric VERGNAUD <eric.vergnaud@jlynx.com>
To: Joris <joris.at.lebbeke@skynet.be>,
        TIFF Mailing List <tiff@remotesensing.org>
Message-ID: <BDDBEC9A.2C99E%eric.vergnaud@jlynx.com>
In-Reply-To: <003701c4dc9d$b2c52fe0$5eb1f551@dfgrrxsknr4e>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
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: 5f44eb75dcd1945252c37fd22222bc1c

le 7/12/04 21:45, Joris =E0 joris.at.lebbeke@skynet.be a =E9crit=A0:

Joris,

Although I "tend" to agree with you, may I simply mention that:
 - libtiff is NOT in charge of the tiff specs
 - the iptc tag is NOT part of the TIFF specs. It's a private tag that
happens to be well known.
 - therefore it's really difficult to state whether the type for that tag
should follow the TIFF specs, or the current reference implementation, even
if the latter is bogus regarding the TIFF specs
 - as I already mentioned, the present and future are ruled by XMP, not by
IPTC, so keeping with a legacy bug to handle legacy data isn't much of a
problem, because the chances that Adobe will correct the bug in PS are
simply null.

Eric

>> Well maybe the first thing to do would be to see what Photoshop IS doing=
.
>> Since Adobe is in charge of the TIFF specs, if they're writing IPTC as a
>> LONG array, then THAT IS the spec, even if it's conceptually incorrect. =
If
>> they're writing UNDEFINED of whatever, then libtiff should definitely
>> follow.
>=20
> Wrong. If Adobe breaks the TIFF spec, that is a different thing from Adob=
e
> changing the TIFF spec.
>=20
> <quote from tiff spec>
> Each TIFF field has an associated Count. This means that all fields are
> actually
> one-dimensional arrays, even though most fields contain only a single val=
ue.
> For
> example, to store a complicated data structure in a single private field,=
 use
> the UNDEFINED field type and set the Count to the number of bytes require=
d to
> hold the data structure.
> </unquote>
>=20
> It's really simple: the data isn't an array of long, so it isn't an array=
 of
> long. This bit about the use if the undefined type is quoted from the top
> decisive spec, and respecting it is logically required for the data to ma=
ke
> sense after applying byte swapping!
>=20
> As to Adobe's current practice, Chris Cox clearly said "Photoshop can rea=
d it
> with any tag type, but writes as type long for compatibility with some
> unspecified application (and the comment has been in there a long time)."=
 This
> goes to show, readers that inappropriatelly compensate for writer bugs is=
 one
> thing, and can be argued to be good, but when writers (the issue here!)
> compensate for reader bugs, then incorrect data is produced and bugs are
> propagated, and matters get worse instead of being corrected, in the long=
 run.
>=20
> I would like to add that logic implies that just about every coder buildi=
ng a
> reader such that it compensate for this writer bug, must have been very
> confused
> at one stage, and must have carefully examined the matter to find out wha=
t was
> the source of the corruption. When coders did that, they must have realiz=
ed
> the
> correct datatype, and most probably made their code to accept it. Thus, b=
y
> correcting the mistake, we would most probably be breaking only the dumbe=
st of
> libraries. In any case, we wouldn't be breaking Photoshop reading of IPTC
> data,
> that's clear from Chris' comment.
>=20
> Bottom line: we will not be breaking apps that were broken anyhow by the
> corrupted data. We will instead restore their correct operation, by curin=
g
> this
> bug. We will also not be breaking the vast majority of bug compensating
> readers.
> Some writers write correct data, most compensating reader coders must hav=
e
> exacmined the issue, and thus most of these compensating readers are very
> likely
> to also accept correct data. We might be breaking a single heap of pasted=
 code
> snippets... so what? The alternative is to keep writing corrupt data, and=
 keep
> breaking the apps that only accept good data.
>=20
> This whole mess, the umpty files with corrupted data out there, clearly
> indicate
> that people with contributing or even CVS writing access to LibTiff shoul=
d be
> required to read and understand the TIFF spec. Otherwise, a threat to the
> integrity of the library and the written data arises.
>=20
> I made my point at least half a dozen times, now. I'm gratefully withdraw=
ing
> now, adding only that I'm a bit put off by this discussion... Aren't we t=
he
> ones
> that should ensure specs are being honoured, instead? Isn't that the sing=
le
> main
> pillar of open data exchange? I strongly dislike the fact that this is be=
ing
> doubted, especially since probably we would probably only be breaking the
> single
> <quote>unspecified application</unquote> that got this bad corruption sta=
rted
> in
> the first place, by correcting this bug, and un-breaking the correct
> libraries.
>=20
> So cure the bug, and document the historical mistake and how to compensat=
e
> for it in existing TIFFs, to try and somewhat make up for the damage that=
 is
> done.
>=20
>=20
> 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
>=20

-------------------------------
Eric VERGNAUD - JLynx Software
Cutting-edge technologies and
services for software companies
web: http://www.jlynx.com
-------------------------------


_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
