Return-Path: <tiff-admin@remotesensing.org>
Received: from inmx009.isp.belgacom.be (inmx009.isp.belgacom.be [195.238.3.146])
        by mailst006.isp.belgacom.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.14) with ESMTP id i3QBgnIb007195
        for <joris.at.lebbeke@skynet.be>; Mon, 26 Apr 2004 13:42:49 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.44])
        by inmx009.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id i3QBgcSc003502
        for <joris.at.lebbeke@skynet.be>; Mon, 26 Apr 2004 13:42:38 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com (localhost.localdomain [127.0.0.1])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i3QBf9n24594;
	Mon, 26 Apr 2004 07:41:09 -0400
Received: from pollux.zylab.nl ([213.201.159.34])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i3QBeZn24559
	for <tiff@remotesensing.org>; Mon, 26 Apr 2004 07:40:35 -0400
Received: from zyback2.zylab.nl (unknown [192.168.1.2])
	by pollux.zylab.nl (Postfix) with ESMTP id A8A8F1DBAC
	for <tiff@remotesensing.org>; Mon, 26 Apr 2004 13:13:34 +0200 (CEST)
Received: from zymail.zylab.nl ([192.168.1.10]) by zyback2.zylab.nl with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 26 Apr 2004 13:38:58 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: Re: [Tiff] Large TIFF files
Message-ID: <44E68E8A7590D411862200508B9AFC2201AFF3A1@zymail.zylab.nl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tiff] Large TIFF files
Thread-Index: AcQrdT4x0MhPhIIrR9ml2kr9LUE0+gAANtZg
From: "Gerben Vos" <gerben@ZyLAB.COM>
To: "Tiff mailing list" <tiff@remotesensing.org>
Cc: "Joris" <joris.at.lebbeke@skynet.be>
X-OriginalArrivalTime: 26 Apr 2004 11:38:58.0875 (UTC) FILETIME=[106178B0:01C42B83]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by yoda.imagelinks.com id i3QBeZn24559
Sender: tiff-admin@remotesensing.org
Errors-To: tiff-admin@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Post: <mailto:tiff@remotesensing.org>
List-Subscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
List-Id: TIFF and libtiff discussion <tiff.remotesensing.org>
List-Unsubscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://remotesensing.org/pipermail/tiff/>
Date: Mon, 26 Apr 2004 13:38:58 +0200
X-UIDL: 291a35f5f7b469af60cae3f24a32654b

Rob wrote:
> > It goes through all tags and replaces all 64 bit tags with 32
> > bit tags leaving all data on the same position.

Joris wrote:
> - as much 'streamability' as possible (current library goes 
> back only to write offset to next ifd)

Rob's proposal would keep streamability unless you (a) don't know
whether you'll be writing 32-bit or 64-bit in advance *and* (b) you want
to write 32-bits downward compatible TIFF as long as that's possible. I
think that's reasonable. You can have two, but not all three. He's just
extending the possibilities. We don't have to implement it yet (see my
later comments on the specification vs. the library).

> - total relocatability (definite requirement)

Not sure what you mean here. Do you mean that it should be possible for
everything to appear anywhere in the file? I.e., everything should be
addressed by 64-bit offsets? Although it may be the best thing to do,
I'm not so sure if it's a definite requirement.

> Just my two cents: I don't like the idea of going back and 
> rewriting all IFD.

Only in a particular case. I suppose a libtiff user would have to turn
on this behaviour. Streamability is important for some people, but it
isn't necessary for everyone. I think it could be a reasonable way to
have some extra backwards compatibility.

> > [fileformat and library are closely related but two 
> > different things]

> Depends. If there is a complete and independent 
> specification, then, yes, there
> is a fileformat that is not defined by the library.

I think it is an absolute must that there is a complete specification
(whoever makes it). Having the format defined by the library would make
updating existing non-libtiff implementations to 64 bits almost
unfeasible.

> I vote  for feasability
> instead: changing minor things to LibTiff, so that 
> count/offsets can be 64bit.

Yes, that would be my idea too, but then change the spec as well as
libtiff. Note that this is largely independent of your previous
sentence!

> Adobe may be bothering to write a spec, which is a good 
> thing, but I don't think
> this list is going to be bothered by that.

We have let that bother us for many years, why stop now? :-) I'm not so
sure libtiff or this mailing list has enough leverage to establish a
de-facto standard. Better to have Adobe and some other major players
(Kofax or other scanner manufacturers?) on board.

> So it is definitely possible that the
> new fileformat is defined by library only.

No, even if we would go solo, we should produce a comprehensive
specification. See how long PNG needed to take off even *with* a good
spec. With only a reference implementation, our attempt is doomed.

> > It is not possible to select allways in advance the right mode, as a
> > user can
> > decide to enlarge a bitmap to > 4GB. When 32 bit mode was chosen and
> > there is
> > a sudden runtime switch to 64bit mode I can imagine quite some
> > difficulties.
> > => So the library must work internally in 64 bit mode.

> The premis, I agree with, but my conclusion is
> => so the library user must specify if it wants to write a 
> 32bit or 64bit file
> in advance, using a flag in the primary TIFFOpen call.

Yes, the library should always internally work with 64 bit pointers,
also to prevent doubling the code size, but it should be possible for a
user to specify in advance which of the two is going to be written. Or
maybe even leave it open.

					Gerben.
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://remotesensing.org/mailman/listinfo/tiff
