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
May 1997

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

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



Valid HTML 4.01!



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

This message was sent to me (ndr@tazboy.jpl.nasa.gov), but
it seemed of general interest, so I cc'd it here:

Jarmo Palom <modultek@unicon-gmbh.com> 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 ftp://ftp.sgi.com/graphics/tiff/TTN1.ps),
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.

<flame>
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.
</flame>

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

I have forwarded this message to tiff@sgi.com, 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.

  --Niles.