1997.03.04 01:38 "Questions on proposed replacement TIFF/JPEG Spec.", by Brian McDougle

1997.03.04 20:01 "Re: Questions on proposed replacement TIFF/JPEG Spec.", by Sam Leffler

You mention in the 'Overview of the solution' section that the JPEGTables field can be stored only once for a multi-segment TIFF file. First, is this 'field' also called a TIFF Tag?

The note tries to adhere to the terminology used in the TIFF 6.0 specification, which is that a field is a whole entry in an IFD (tag and value), whereas the tag is just the numeric identifier assigned to a particular field. Older versions of the spec tended to use "tag" for both meanings, and many people still say that informally.

Second, am I correct that when you refer to a multi-segment TIFF file you are referring to a TIFF file with multiple images (i.e. a multipage TIFF file), or is "multi-segment" in reference to the JPEG compression?

The note defines "segment" to mean "strip or tile", since it would otherwise have to say "strip or tile" incessantly. This terminology isn't used in the TIFF standard (although I think Adobe might be well advised to adopt it in TIFF 7 :-)).

Actually, since a strip is just a tile with the known width (ImageWidth); I'd prefer to cast things in terms of tiles; but this is unlikely given that most folks familiar with TIFF know about strips but not tiles.

Third, if a multipage TIFF file is generated will each image that uses this proposed compression scheme require a separate JPEGTables field?

In a multipage (multiple IFD) TIFF file, each IFD is independent. AFAIK no other field values are assumed to be carried over from one IFD to the next, so I wouldn't expect JPEGTables to be either. In other words, yes, you need a separate JPEGTables for each JPEG-compressed page.

My concern is that this field is a TIFF tag and each page of a multipage TIFF file may contain a JPEGTables tag that references the same offset within the TIFF file. This use of "duplicate pointers" is prohibited by the TIFF specification as defined in Section 7 (Additional Baseline TIFF Requirements) of the TIFF 6.0 specification.

Right, making them all point to the same place would be a violation of the duplicate-pointer prohibition. You could get away with it in practice, for many TIFF readers, but I wouldn't recommend doing it.

However, while it is easy in most file systems to "seek" back to a position in a file, there are circumstances when this is not possible.

A reader not capable of seeking in a file is unlikely to be able to deal with most TIFFs, I think. I have heard of a "streamable TIFF" subset of TIFF, which imposes field location restrictions to make TIFF serially readable, but I do not know the details. It's not widely used, anyway.

STIFF (Stream TIFF) is a thing that some folks at SGI did for the Impressario printer product. STIFF is ostensibly TIFF but not quite; it violates the spec in one subtle way that may cause readers to complain about the files (my library has a small hack to silence the complaint it would normally make). It also restricts app usage to a fixed set of tags (so the header can be written ahead of the image data). As far as I'm concerned STIFF is pretty much useless because it does not support encoded (i.e. compressed) image data. It was originally conceived to avoid using an intermediate file when passing image data around between apps in a printer pipeline. My experience is that if the OS supports memory-mapped data and a reasonable VM system you don't get much of a performance gain by passing the data through a pipe (versus using a temp file and mmap'ing it).

Sam