Status: Read
Received: from [207.113.13.68] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Tue, 8 Jun 1999 23:30:22 -0400
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id XAA20490;
	Tue, 8 Jun 1999 23:06:38 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Tue, 8 Jun 1999 23:05:35 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id XAA20467
	for tiff-outgoing; Tue, 8 Jun 1999 23:05:34 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from mingus.lumisys.com (root@mingus.lumisys.com [204.153.44.5])
	by gate7.olympiakos.com (8.8.7/8.8.7) with ESMTP id XAA20464
	for <tiff@olympiakos.com>; Tue, 8 Jun 1999 23:05:31 -0400
Received: from porter.lumisys.com (porter.lumisys.com [204.153.47.67])
	by mingus.lumisys.com (8.8.7/8.8.7) with SMTP id UAA04666
	for <tiff@olympiakos.com>; Tue, 8 Jun 1999 20:27:27 -0700
Received: from lumisys.com (sfr-qbu-pqq-vty33.as.wcom.net) by porter.lumisys.com (5.x/SMI-SVR4)
	id AA10874; Tue, 8 Jun 1999 20:06:46 -0700
Message-Id: <375DD9E0.7E5D563C@lumisys.com>
Date: Tue, 08 Jun 1999 20:05:04 -0700
From: glen <glen@lumisys.com>
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
Mime-Version: 1.0
To: TIFF Mailing List <tiff@olympiakos.com>
Subject: Re: Large File Support
References: <E130F8876BE8D211A2B90008C7CBFB48A776E9@usexch01.sd.gd.com> <37574BDB.6367B7B5@home.com> <375B7893.1B4E1640@zeiss.de> <375BC314.8DD77C3C@home.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@olympiakos.com

Folks,

Here's my two cents.  Being just a _little_ incompatible is just about as bad as
being a _lot_ incompatible.  Therefore, "in for a penny, in for a pound".  Let's
just do the whole thing at once, make a completely new header and solve this thing
more or less all at once.

A nice way to handle it would be to add a layer to handle TIFF files like a
Microsoft "COM" object.  The idea is that you query the layer as to what interface
(e.g., 64-bit vs. 32-bit) the object (i.e., TIFF file) supports.  So a new program
with the ability to handle 64-bit integers would ask for the 64-bit interface
first, and if the header is an "old" version with 32-bit stuff, than that query
fails.  The program would then ask if the file supports the 16-bit version, and of
course it does.  Fine.

If your program only can handle the 32-bit integers, don't even ask for the 64-bit
interface.  Just ask for the 32-bit.  Now, if the file is a "native" 32-bit
version, the query will succeed.  If it is a newer 64-bit version, then it would
fail (unless, *perhaps*, the new layer could scan the header and guarantee that all
64-bit integers could fit in 32 bit.

I think anything we do is apt to be major.  At least this would be an elegant way
of handling the differences between old and new files and old and new programs /
TIFF libraries.  Eventually all (yes, *ALL*) programs would have to / should be
changed to use the new layer.  But at least this would eventually solve the
problem.

What do you all think?

P.S. -- Any bets as to when 64 bits will not be enough?

Frank Warmerdam wrote:

> Rainer Wiesenfarth wrote:
> > I'd prefer the professional way rather than the quick-and-dirty one: If
> > offsets in the file are changed to be 64 Bit, then ALL offsets should
> > be changed.
>
> Rainer,
>
> Given time to reflect, I agree that my proposal would lead into a morass
> of problems somewhat akin to segmented programming on the x86.  I agree
> that a better approach is 64bit offsets used everywhere offsets apply.

> <snip>

> I suppose so.
>
> Because this approach requires fundamental changes to the directory format
> I think it will be significantly harder to pull off than the offset32 approach.
> Now I am waffling again.   It makes my brain hurt.
>
> Regards,
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turned up | Frank Warmerdam, warmerda@home.com
> light and sound - activate the windows | http://members.home.com/warmerda
> and watch the world go round - Rush    | Geospatial Programmer for Rent

