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>; Mon, 7 Jun 1999 09:32:48 -0400
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id JAA16134;
	Mon, 7 Jun 1999 09:11:29 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Mon, 7 Jun 1999 09:01:27 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id JAA16092
	for tiff-outgoing; Mon, 7 Jun 1999 09:01:25 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from mail.rdc1.on.home.com (imail@ha1.rdc1.on.wave.home.com [24.2.9.66])
	by gate7.olympiakos.com (8.8.7/8.8.7) with ESMTP id JAA16089
	for <tiff@olympiakos.com>; Mon, 7 Jun 1999 09:01:22 -0400
Received: from home.com ([24.65.34.185]) by mail.rdc1.on.home.com
          (InterMail v4.01.01.00 201-229-111) with ESMTP
          id <19990607130117.ZRKU18962.mail.rdc1.on.home.com@home.com>
          for <tiff@olympiakos.com>; Mon, 7 Jun 1999 06:01:17 -0700
Message-ID: <375BC314.8DD77C3C@home.com>
Date: Mon, 07 Jun 1999 09:03:16 -0400
From: Frank Warmerdam <warmerda@home.com>
X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.27 i586)
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@olympiakos.com

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. 

> In addition, some other changes could be discussed in this context:
> - the 'Count' field in the Directory Entry should also be 64 bit. This
>   will not be neccessary for today's needs, but who knows what tomorrow
>   will bring us.
> - maybe the 'Tag' field should be extended to 32 bit. This is only to
>   avoid a further redefinition of the basics of TIFF.
> - maybe the 'Type' field should be extended to 32bit. This would make
>   the Directory Entry size a multiple of 8.

I suppose that since the directory format would already have to change to
handle the 64bit NextIFD, and Offset values, it wouldn't hurt to do the
rest.  

> - as the size of the offset is now 64 bit, more data (e.g. 8 bytes)
>   can be packed in the offset field without the need for redirection.

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
