2004.04.22 07:38 "Re: [Tiff] Large TIFF files", by Rob van den Tillaart

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 :)

regards,
rob tillaart