AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1999.06.03 19:48 "Large File Support", by Bruce Forsberg
[...]
1999.06.09 13:33 "Re: Large File Support", by Frank Warmerdam
1999.06.09 14:08 "RE: Large File Support", by Ed Grissom
1999.06.09 15:50 "RE: Large File Support", by Rainer Wiesenfarth
1999.06.09 18:50 "Re: Large File Support", by Chris Barker
[...]

1999.06.09 14:08 "RE: Large File Support", by Ed Grissom

Of course, keeping essentially the same model with modest changes in the format to support larger numbers should go a long way to satisfying that objective.

As far as I can tell, here are the necessary changes:

++++++++++++++++start of changes++++++++++++++++++++++

Initial file bytes changes:

New Data Type definitions:

LONG64 - A 64 bit unsigned integer
SLONG64 - A 64 bit signed integer"

Tag Definition:

A tag is now made up of 16 bytes, the last field is 8 bytes long, and either contains the data (if it will fit in 8 bytes), or an 8 byte pointer to the location of the data.

Redefinition of Existing Tags:

All tags that currently require a 4 byte pointer to data will use an 8 byte pointer in the new format.

++++++++++++++end of changes++++++++++++++++++++++++

The data offset tags (stripoffsets, tileoffsets) will _have_ to contain 8-byte pointers. Other TAGs that use offsets ( resolution, bits/sample/band ) will almost certainly have to use 8-byte pointers also, since we cannot guarantee the location that this data will be stored at.

I don't see how we can put an 8-byte pointer in _some_ TAGs without changing the size of all TAGs. Since we are redefining the size of a TAG structure, I would not say that the changes are modest.

As far as contacting Adobe, I tried a variety of email addresses, but the only one that responded was the "mail customer support" link on the www.adobe.com web site. I don't think it was on the main page, but somewhere under customer support.

Unfortunately, the response I got was a canned message to call the 1-800 number.

--
ed grissom
egrissom@ziimaging.com