TIFF and LibTiff Mail List Archive

1997.05.02 10:34 "Re: TIFF multiresolution files", by Niles Ritter

This message was sent to me (, but it seemed of general interest, so I cc'd it here:

Jarmo Palom <> writes

> I would like to get information about using TIFF multiresolution images. The
> TIFF 6.0 specifications don't say much about that; only, that in a TIFF file
> some TIFF image headers may have a tag (NewSubfileType) with option "reduced
> resolution". Especially the following questions are important:
> - How does reduced resolution images depend on the full resolution images.
> Must they follow immediately? Should they have the same page number?

All the TIFF 6.0 spec says is that if multiple subfiles are written, the first one *MUST* be "the full resolution image" (pg. 26). This of course implies that there is only one full-res image, and there may be many. The spec also says that there is no requirement for pages to be in sorted order.

In any case, the "thumbnail" image(s) can follow after the primary. In a reasonable world, the page numbers (if any) should be the same, since they refer to the same document page. This would, however, screw up page reading software that assumed that the page numbers were unique. And the TIFF spec itself is a little vague on the PageNumber tag, the second value of which is the "number of pages in the document", the problem being whether "document" means "file" or not, and whether "page" means "IFD" or not. If it does, then it is a very delicate tag and easy to break. Personally, I dont think it does...

Multipage/resolution in TIFF 6.0 is messy, since all the images have to get shuffled together into a single linked-list of directories. To address this problem, Aldus (now owned by Adobe), came out with Tech Note #1 dated June, 1993 (available at, which advances the concept of a "tree". The idea is that the main linked list of image directories (IFD's) should be the full-resolution pages, and any associated thumbnails, alpha masks, etc should be in an IFD "branch" from each main image node.

To do this, Aldus defined the SubIFD tag = 330, which may be a multi-valued tag of offsets to other IFD's associated with this image node. The LIBTIFF package supports one-level linkage of these trees (ie, you can't have a SubIFD of a SubIFD), which is more than most folks would need.

Not everyone supports this extension, however (no surprise), so beware if you need to be inter-operable with someone else. It is, however, the right way for TIFF to handle multi-resolution/multi-page files, IMHO.

> - Is it allowed for the reduced resolution image not to define certain tags
> (e.g. Compression, TileWidth, TileHeigth) and assume, that those values are
> taken from the full resolution image? (I have found some TIFF files with
> this property!)

In a word, No.

In two words, No Way.

In three words, No Way, Jose.

In four words, Not on your life.

Each image must have all Section 7 Required Tags, and cannot assume/depend on the existence of other images in the file. To do so breaks the "No Duplicate Pointers" requirement, that no data should be referenced from more than one place in a file (pg 26). This would also break the spec on ImageLength, Width, which clearly state that they have "no default" values.


If you have found such files, they are bogus, the software that created them should be discarded, and the developers that wrote the software should be verbally abused, held up for public ridicule, then buried along with their code and the bogus TIFF file they created.

And the ground in which they are buried should be sown with salt.

Some very large organizations have been known to write such garbage, and Sam Leffler's libtiff software is full of comments where he grumbles about having to accomodate improperly written TIFF files.


> - If You cannot give me answers, are there any othe places, where I
> could try?

I have forwarded this message to, where TIFF issues are commonly discussed.

> Are there any places, which could e.g. tell, if some TIFF headers > are legal?

It is not a sure-fire bet, but in general, if the libtiff "tiffdump" or "tiffinfo" has problems with the file, it is 99 times out of a hundred the fault of the file, not libtiff.