2004.04.15 00:26 "[Tiff] Large TIFF files", by Lynn Quam

2004.04.21 17:54 "Re: [Tiff] Large TIFF files", by Chris Cox

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)

I would break the possibilities down farther:

  1. break with existing and keep as much compatibility as possible
  2. break with existing and keep only the good ideas, but not value compatibility (meaning that tag values will change, and we can clean out some cruft)

Note that cruft has the nasty attribute of allways appearing again in some way :)

True - but we could also add things to the specification to try and prevent similar cruft from reappearing (or the same mistakes from being made again).

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 (like @#$%@%# GEO-TIFF).

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

Some people have suggested that ASCII based tags would make debugging far easier - and if we're going to 64 bit values we can use 8 byte tags as well.

tag: 'ICCProfl', 'Compress', etc.

I like this idea but the BTIFF/BIF format is for computers first, a dump tool can make it human readable. Doubt if 8 chars will be enough remember the 8.3 filename style.

It would be better than 4 byte or 4 character tag types. Arbitrarily sized tag types would make it a little more difficult to parse, even if it makes it easier to read.

And when writing the libraries, it's helpful to be able to read the file format in a hex editor ;-) Also, sometimes it's useful to report or list the unknown/unrecognized tags for an end user - and the more information you have, the better.

Reminds me that some time ago I was thinking about an XML version of TIFF. Readability would be improved (although XML considered readable??). We could use all kinds of XML tooling developed during the internet hype. The filesize would however expand at least with a factor 2, processing it takes extra overhead. Some time ago I read about an comparison between ASN-1 coding (strict binary) and XML (strict ascii) and the differences in performance went up to a factor 6. (in an IEEE magazine).

XML for images - that should remain a contradiction in terms.

Chris