AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
June 1999

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

Valid HTML 4.01!


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

  a) Powerful and flexible for just about any purpose within its scope
  b) So flexible that one can write very "Obfuscated" entities with it,
       which are nonetheless compliant with the language spec
   c) Designed at an early stage in the development of the domain
         (e.g no object oriented design)
   d) 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

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

The Java answer to C can be described as

  i) A complete rewrite of the original language, no backward
 ii) Omitting anything that does not fit the new model, lots of new
      found missing in the original language (e.g. garbage collection),
      things that have caused big problems (e.g allowing pointers).
iii) 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) Ideally, the next generation TIFF would be backward compatible
to the extent that it does not interfere with the needs of new
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
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
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
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
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
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

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.