-
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.09 15:52 "RE: Large File Support", by Ed Grissom
- TIFF magic number changes from "42" to "84" (double 42 ??)
I'd prefer 66 (= 0x42) or 258 (a base 64 noted number 42) to keep the meaning behind it
Sounds ok to me. I kind of prefer the 66. That way it would show up as 42 in hex editors. My main point was that it must be changed.
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.
If we do changes, our goal should be not to change it again two years later. So maybe the following changes should also be done:
- the Count field of an entry should also be 8 bytes. No one will use tiles or strips with more than 4 GB data today, but who knows about tomorrow?
- the Tag field may be expanded to be 4 bytes to have plenty of tags left for future enhancements.
You are right, of course, and I believe that your suggestions were in a previous message that I did not read closely enough. Had I done so, I would have included them in my summary... The count field may be necessary sooner than you think, planar configuration RGB files with 1 line/strip can get a very large count very quickly with SAR data (typically very long but not very wide)
--
ed grissom
egrissom@ziimaging.com