|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
2004.04.22 10:32 "Re: Large TIFF files", by Gerben Vos
Hi, neither I nor the company I work for seem to have a stake in a 64-bit TIFF format in the foreseeable future, but I hope I may mutter a bit from the sideline occasionally. :-) Being the most evolutionary approach, I would like to see Frank's proposal being discussed a bit more. > o Introduce a new data type TIFF_LONGLONG = 14 which is a 64 bit > integer value. > o Allow as a non-core extention the option of having the strip > offsets or tile offsets as TIFF_LONGLONG. > o leave everything else the same. This means that all directories and ancillary data must be forced below the 4GB limit, which makes writing the TIFF harder. On the other hand, TIFF reading apps can be upgraded almost trivially. (This seems a bit against the current TIFF philosophy, which makes writing easy and reading hard.) We could introduce a tag similar to SubIFD (330) to point to a directory in 64-bit space, but that would be adding to the cruft. If we take a more revolutionary approach, I think we should liberally borrow ideas from the PNG spec, like their ASCII-transfer-detecting header and the bit that indicates whether unknown tags should be copied. Also in that case, I would slightly prefer ASCII-like tags, it gives my eyes something to hang on to when viewing a TIFF in a hex editor (which will remain useful for corrupted files and derived-but-not-quite-TIFF formats like Microsoft's Office Document Imaging format). I'm sure Chris will bring in the lessons they've learned at Adobe when creating their PSB/Large Document Format. Also, W3 5H00LD K4LL 7H3 F1L3 F0RM47 BIFF!!!!!!!!111!!!! CU2 B1FF R00L2 4ND H3'Z L33T!!!!!!!!11111111!!!!!!!!!!!!!!!! (Sorry, couldn't let that bit of Usenet history pass by.) Gerben Vos.