LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.04.22 07:38 "Re: Large TIFF files", by Rob Tillaart
Chris Cox wrote: > > At 9:30 AM +0200 4/21/04, Rob van den Tillaart wrote: > > Chris Cox wrote: > > > > > > Professional Photoshop users needed 64 bit TIFF now. > > > Some high-end print users needed it about 3 years ago. > > > > How does Photoshop solves this need today? > > Photoshop CS introduced a new filetype (PSB/Large Document Format) > for documents over 30,000 pixels in either dimension and that uses 64 > bit offsets. The format has to be enabled in preferences so that we > can show dire warnings about the format compatibility. > > But, it is not a public format, and there is no public library for > reading the format. > So we really need a TIFF or TIFF like solution as well. > (and the last few times I brought it up the discussion didn't get anywhere) As you see the discussion fire is burning again, and if my spare time permits, it will be burning until the goal is reached. imho the goal is support for large files > 4GB. There are many other problems to be solved in the TIFF format, but if we go the evolutionary way we must: - list the problems (cluster related issues) - priortize them - solve them one (cluster) at the time as professionals. - Look at alternatives - choose - document - build large files is now on the top of the list. [proprietary tag (&cruft) discussion] > For instance - defining a mechanism for indicating which proprietary > tags should be preserved, which tags should be removed, and which > should be updated (preferably with public documentation on HOW to > update them) when editing an image would help a LOT of situations Lets ask all owners of proprietary tags to send such a description to the mailing list. Then they will appear in the TIFF archive (kudos to Joris) and maybe if time permits a webpage can be made on which you can search for proprietary tags. [need for processing tag discussion] > And defining an order of image compression operations (as an example: > "decode in this order: decompress, byte swap to platform native, > reverse predictor, then apply scaling and inversion as necessary for > your application") would also help developers understand how TIFF > works and avoid problems when trying to define new schemes (some of > which have broken this flow). Important problem, lets put it on the list. Question: should this be human readable, or machine readable. [readable tag discussion] Good points, for a new file format tags could look like: TAG -------------- 8 BYTE TAGNR long 16 BYTE TAGNAME string 8 BYTE TYPE long 8 BYTE LEN long 8 BYTE VALUE or OFFSET long This way tags are more or less self documenting, as they have an explicit name, on the other hand software could just read the number. Another solution could be the METATAG discussed in an earlier mail. > And when writing the libraries, it's helpful to be able to read the > file format in a hex editor ;-) Real programmers dream in hex :) > Chris regards, rob tillaart