TIFF and LibTiff Mail List Archive


1999.06.20 23:05 "64-bit TIFF Meta-issues", by Niles Ritter
1999.06.21 06:31 "Re: 64-bit TIFF Meta-issues", by Niclas Borlin

1999.06.20 23:05 "64-bit TIFF Meta-issues", by Niles Ritter

Continuing on with the 64-bit TIFF discussion, I have a few remarks on the valuable contributions of Frank Warmerdam, Ed Grissom, et al,

This is more a metaphorical observation. I submit that TIFF could be thought of as an image-description "language", and shares features with the programming language C, based the fact that both are

  1. Powerful and flexible for just about any purpose within its scope
  2. So flexible that one can write very "Obfuscated" entities with it, which are nonetheless compliant with the language spec
  3. Designed at an early stage in the development of the domain (e.g no object oriented design)
  4. Showing signs of age with the advance of technology

Within the world of programming languages, C++ and Java both arose to address different problems arising from (a)-(d).

The C++ answer to C can be described as

  1. An augmentation of the original design, backward compatible
  2. with new features and exceptions to (i) to accomodate new technology or knowledge about the domain (e.g objects, type safety)..
  3. Completely public, not controlled by any private organization

The Java answer to C can be described as

  1. A complete rewrite of the original language, no backward compatibility
  2. Omitting anything that does not fit the new model, lots of new features found missing in the original language (e.g. garbage collection), and things that have caused big problems (e.g allowing pointers).
  3. Open standards, but controlled by a private company (Sun, Inc).

I should also mention Postscript, also owned by Adobe, which actually *is* a true programming language with an auxilary imaging model space, and is so general that virtually any sort of graphical object that could ever be imagined can or could be described by it. Great for printing graphics, terrible for interchanging data.

The nice thing in our case is that we don't have to choose between C++ or Java solutions, but can take the best of both for each of (i)-(iii):

(i) Ideally, the next generation TIFF would be backward compatible to the extent that it does not interfere with the needs of new developments in the imaging domain. I for one have not been convinced that it is necessary to advance to a "non-version 42" stage to accomodate 64-bit and higher address space (isn't there a 128-bit chip in the works ?).

The "spirit of TIFF" regardless of whether held by Microsoft, Aldus or Adobe, has been that a valid TIFF file should always be readable by any later TIFF reader, and that new TIFF files should have a way to be at least "visible" to older readers, if they can.

(ii) There are some things in TIFF spec that have proven to be bad choices, if for no other reason than that they seem to invite bad implementations (releasing an ambiguous & unworkable JPEG-in-TIFF spec before submitting it to technical review as the most notorious example). For this part I tend to lean toward the Java option of throwing away things in a brand new implementation that are were ideas.

For example it is not possible to create a backward compatible TIFF file spec that is web/stream-oriented by having all tile-offsets pointing after an IFD, because a TIFF copier might just reorganize them again copying all the tags. Your only protection is to guarantee that existing TIFF copiers break.

(iii) on this one I am more ambiguous. The way that Sun has been able to hold its own against Microsoft's J++ "embrace, extend, and break" attack on Java I see as evidence that a private company can maintain an open standard. On the other hand, Adobe's recent accelerated neglect of TIFF support causes me pause.

Adobe owns the copyright to the TIFF name. They also maintain the private registry, and if we were to just start our own registry and begin using tags unregistered by Adobe, they may allocate the same tags for other purposes, and suddenly you have competing standards, and TIFF is dead for any future purposes.

Assuming Adobe does not suddenly have a change of heart, the only alternative I can see if we wish to call the next generation TIFFwhatever is for a public organization to purchase the copyright and the residual tag-space registry from Adobe. I have no idea what that would be worth.

Obviously my personal choices on (i) - (iii) are in conflict with each other to some extent, but there are ways to make it work. For example, you could define a TIFF64 header that starts with a block of 8 bytes not used by TIFF64, followed by the TIFF64 header information. This initial 8-bytes could be set to a TIFF 6.0 header, version=42, pointing to 32-bit "thumbnails", or it could be a TIFF header which has version=45, telling all existing TIFF readers that there is nothing of value in this file for TIFF 6.0 programs and they will give up.

In any case these general decisions should be made earlier than later, particularly the issue of whether we should court Adobe's involvement or representation in the process, and whether TIFF "can be saved" or should.

Just a thought.