Received: from [207.113.13.68] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Fri, 4 Jun 1999 14:54:16 -0400
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id OAA09949;
	Fri, 4 Jun 1999 14:37:41 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Fri, 4 Jun 1999 14:35:12 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id OAA09926
	for tiff-outgoing; Fri, 4 Jun 1999 14:35:12 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from ns1.marconiis.com (firewall-user@ns1.marconiis.com [206.19.115.2])
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id OAA09923
	for <tiff@olympiakos.com>; Fri, 4 Jun 1999 14:35:09 -0400
Received: by ns1.marconiis.com; id LAA06288; Fri, 4 Jun 1999 11:34:46 -0700
Received: from usexch03.marconi-is.com(134.120.81.11) by ns1.marconiis.com via smap (4.1)
	id xma006091; Fri, 4 Jun 99 11:34:29 -0700
Received: by usexch03.sd.gd.com with Internet Mail Service (5.5.2448.0)
	id <M29D0FLB>; Fri, 4 Jun 1999 11:35:47 -0700
Message-ID: <E130F8876BE8D211A2B90008C7CBFB48A776EB@usexch01.sd.gd.com>
From: "Forsberg, Bruce" <Bruce.Forsberg@marconi-is.com>
To: "'tiff@olympiakos.com'" <tiff@olympiakos.com>
Subject: RE: Large File Support
Date: Fri, 4 Jun 1999 11:35:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-tiff@olympiakos.com

 
Thanks for all of the replies.

Again I am not a TIFF expert. I was probably looking at the count field
and thought that was a total file size. My mistake.

I would think this could be fixed in two phases.

1) Add the capability to open/create tiff files > 2 GB. This could be
done with a compiler directive that would use the transitional APIs that
support file sizes greater than 2 GB. Of course this would be a problem
if someone created a TIFF library on Solaris 2.6, which has the transitional
APIs, and then tried to use it on Solaris 2.5, which does not have the
transitional APIs. This fix would at least, as it sounds to me, write and
read (uncompressed) TIFF files to something less than 4 GB.

2) Somehow modify TIFF spec to support > 4GB images. The best approach
for me would be an implementation that if one wrote a large image, say
5 GB, one could still read it to a 2 or 4 GB limit with the old spec
or library. This would have a bad side effect in that the user might
think they were viewing the whole image when they were not and they would
have no way of knowing it. Another posibilty, that I think was mentioned
by someone, was modify the spec to support large files. When one creates
a file < 2 GB use the tiff 6.0 spec to create the image with its magic
number. If one creates a > 2 GB image use the new modified spec with a
new magic number. This way < 2GB images created with the new library will
still be able to be read with the old library.



I am with Marconi Integrated Systems's Imagery & Information Systems unit.
Our customers are asking more and more for large imagery support and I am
modifying our software to handle this and seeing what image formats we
can support.


I think I have answered most of the questions that were asked of me.


Thanks,

Bruce Forsberg
Marconi Integrated Systems
