Return-Path: owner-tiff@olympiakos.com
Return-Path: <owner-tiff@olympiakos.com>
Received: from localhost (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8B92oMq019915
	for <dron@localhost>; Tue, 11 Sep 2001 13:19:03 +0400
Received: from eudoramail.com [209.185.123.45]
	by localhost with POP3 (fetchmail-5.9.0)
	for dron@localhost (single-drop); Tue, 11 Sep 2001 13:19:03 +0400 (MSD)
Received: from gate7.olympiakos.com ([207.176.88.85]) by shared1-mail.whowhere.com; Mon Sep 10 09:02:51 2001
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id LAA30062;
	Mon, 10 Sep 2001 11:41:49 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Mon, 10 Sep 2001 11:37:12 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id LAA29987
	for tiff-outgoing; Mon, 10 Sep 2001 11:37:12 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from woodstock.jcpenney.com (woodstock.jcpenney.com [146.235.10.52])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id LAA29984
	for <tiff@olympiakos.com>; Mon, 10 Sep 2001 11:37:09 -0400
Received: from uns-dv1.jcpenney.com (uns-dv1.jcpenney.com [10.33.239.136])
	by woodstock.jcpenney.com (8.11.6/8.11.6) with ESMTP id f8AFaxx17115
	for <tiff@olympiakos.com>; Mon, 10 Sep 2001 10:37:00 -0500 (CDT)
Received: (from jschumac@localhost)
	by uns-dv1.jcpenney.com (8.9.3+Sun/8.9.1) id KAA11502
	for tiff@olympiakos.com; Mon, 10 Sep 2001 10:28:41 -0500 (CDT)
Date: Mon, 10 Sep 2001 10:28:41 -0500
From: Joel Schumacher <jschumac@jcpenney.com>
To: tiff@olympiakos.com
Subject: Re: workaround for TIFF file limit size ?
Message-ID: <20010910102840.A12916@jcpenney.com>
References: <010101c138a6$e0db7590$db042cd5@tapon>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <010101c138a6$e0db7590$db042cd5@tapon>; from pjg@club-internet.fr on Sat, Sep 08, 2001 at 10:43:12PM +0200
X-VirusScan: JCP virus scan detected no virus
Sender: owner-tiff@olympiakos.com
Status: RO
Content-Length: 1719
Lines: 36

pjg@club-internet.fr (pjg@club-internet.fr) wrote :
> Does anyone know a workaround for TIFF file limit size of 4 GB (Tiff
> compression is not useful for me) ? A patch for libtiff ? Another tiff
> library ? Other tip ?


Probably the reason for a 4GB limit is that Tiff files have 32-bit
pointers to places within the file.  And the limits of a 32-bit
number are 4,294,967,295.

I suppose the quickest approach would be to make yourself a 64-bit
pointer and adjust libtiff to handle that.  Probably need to define
your own 64-bit data type also, because I'm pretty sure some of the
tag values will probably need more room if you go beyond 4gb also.

But at that point, it really doesn't become a TIFF anymore - at least
not something anything else will read.  This is a fundamentally
different change than, say, adding your own new compression type in
the TIFF wrapper.  That's something some viewer might not be able to
handle and can report that.  But what you're proposing is changing the
TIFF wrapper itself, making it unrecognizable as a TIFF file.  Or
causing unpredictable results because the viewer is only looking at
half the address pointer.

So I kind of have to question the point of trying to use TIFF or
modify libtiff.  Especially when you say TIFF compression isn't useful
for you.

Using a standard format would be best, but if you can't find one, why
not compress it how you want to and store it in some new format of
your own creation?

______________________________________________________________________
Joel Schumacher                    JCPenney Co. - UNIX Network Systems
jschumac@jcpenney.com              12700 Park Central Pl   M/S 6021
(972) 591-7543                     Dallas TX  75251

