-
1999.06.04 03:45 "Re: Large File Support", by Frank Warmerdam
-
1999.06.07 13:00 "Re: Large File Support", by Rainer Wiesenfarth
- 1999.06.07 13:03 "Re: Large File Support", by Frank Warmerdam
- 1999.06.08 21:14 "Re: Large File Support", by Peter Smith
-
1999.06.07 13:00 "Re: Large File Support", by Rainer Wiesenfarth
- 1999.06.04 07:32 "Re: Large File Support", by Rob Tillaart
- 1999.06.04 18:35 "RE: Large File Support", by Bruce Forsberg
- 1999.06.10 09:48 "Re: Large File Support", by Klaus Bartz
- 1999.06.10 15:10 "Re: Large File Support", by Peter Smith
- 1999.06.14 11:16 "Re: Large File Support", by Martin Bailey
1999.06.14 11:16 "Re: Large File Support", by Martin Bailey
I've been pondering the idea of large file support, and especially the ideal of minimising the impact that any changes would have on existing readers etc. I see backward compatibility as extremely important to ensure that any changes would be acceptable both to application creators and to the user community. As others have already said, we really don't need a new file format right now.
As I see it the minimum change would be:
- Require that all FIDs and indirectly referenced tag values fall within the first 4 GB of the file. This means that FID pointers in the header and at the end of each FID, and value pointers can all remain as 4 bytes. In a very large file it may be more efficient for some readers if the FIDs are at the start of the file anyway.
- Add a new tag type - LONG64, maybe also a signed version - SLONG64, with a strong recommendation that they only be used where required.
- Adjust some tag descriptions, e.g. StripOffsets may currently use a SHORT or LONG value, add LONG64 to the valid types.
Yes, I know this is a somewhat cludgy, but changes to existing formats where backward compatibility is an important consideration tend to be.
I also realise that this simple suggestion does not necessarily mean that it would be simple to update applications to work with large TIFF files. If a tool is not 64-bit ready it will still be hard to amend it.
What do people think?
Regards
Martin Bailey
----------------------------------------------------------
Digital Print & Publishing Harlequin Ltd
martinb@harlequin.com http://www.harlequin.com
----------------------------------------------------------
I try to ensure that my views expressed here accord with
my employers, but I am not a spokesman for Harlequin and
the buck stops with me for what I say here
----------------------------------------------------------