• Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).

TI/A – Some general considerations

I would like to open a discussion about some basic characteristics that TI/A should follow (as well as other archival formnats):

As we all know, longevity of digital data depends on 2 prerequisites:

  1. The bitstream has to be preserved. This means, that the medium the bits are written on can be read again and the bits fed into a computer. There are basically 2 methods for doing this: a) data carrier migration and b) using a stable, technology independent medium (such as barcodes on microfilm).
  2.  The bits have to be interpreted, or in other words: the semantics of the bits has to be known. Usually we call this the file format.

It is obvious that with TI/A we address the second issue. When is a file format long living? In my opinion, there are several criteria:

  1. It must be well documented, and the documentation must bee freely available and distributed
  2. No properietary or patented features
  3. Simplicity
  4. Widespread use

If we look at this points with the TIFF in mind, we can state, that 1) is fullfilled, 2) proabably yes (not in the cases of TIFF/EP, since TIFF/EP may contain propriatery information); forTIFF/IT I'm not totally sure, 3) will be discussed below, 4) is ok.

I strongly believe that simplicity is an crucial issue. Let's think 25 or 50 years ahead. Computers will look different, operating systems will look different, some brands and some technologies may have vanished (who still remebers VAX/VMS from DEC – I sill have a lot of software I wrote for this machines which I would like to reactivate...). If we (or our children :-) want to read an old TIFF file, eventually none of todays free TIFFreaders will compile. They [our children] will have to redevelop a new TIFF-renderer using the documentation. At this point, simplicity comes in: if the specs are simple and easy to implement, it will be done. If it's hunderts of pages of complex algrorithms, it will be expensive and require a long development process which eventualy can not be afford. Thus simplicity is – IMHO – mandatory.

TIFF can be simple, but – because the specification is so flexible – can also be very complicated. TI/A should define a subset of the TIFF-specification that enforces simplicity. No complex data compression schemes, simple IFD-structure etc. Thus a TI/A file can be read by any of the modern TIFF-readers, but at the same time, it will by a matter of days to develop a new TI/A-reader in 2115. Therefore I would like to design TI/A as a simple, basic format forming a subset of TIFF 6.0 and thus remaining totally compatible with todays software.



Defining TI/A as a subset of TIFF 6.0 alone would be problematic. The three Technical Notes are, by universal practice, part of the "TIFF specification." Certain relaxations of the specification are generally accepted, such as allowing odd-numbered value offsets and treating certain value types intechangeably. The ICC Profile tag is certainly needed; it's defined in TIFF/IT and TIFF/EP, but not in TIFF 6.0.

A strict subset of TIFF 6.0 would not be compatible with today's software. A great many files would break because they don't observe the even-numbered value offset requirement. Defining what we mean by "TIFF" isn't as easy as it would be with better-defined formats, and it's necessary to approach the question with great care.

I'll be in Wernigerode, Germany for the next week and may not have access to a computer with a good keyboard, so I'll most likely have to disappear from these discussions till about October 7.


I am curious how everyone feels about multiple IFD's within a TIFF. This can be multiple images in one or in some cases a thumbnail. Is keeping a "simple IFD-structure" mean just one IFD? Some software is not compatible with multiple IFD TIFF's, Adobe Photoshop only reads the first one.


If Exif is supported (I think it should be) then the special case of Exif IFDs needs to be allowed. There are three of these, which are identified by the tags that point to them and the tags they hold: the "Exif" IFD, the GPS IFD, and the Interoperability IFD. They don't hold an image, only metadata.

For IFDs that represent actual images, I'll defer to those with more practical experience.