TIFF and LibTiff Mail List Archive


1998.09.22 14:49 "TIFF Questions - TIFF 7.0 ?", by Ed Grissom
1998.09.22 14:51 "Photometric interpretation of multi-band, NON-alpha images ?", by Ed Grissom
1998.09.23 15:15 "RE: Photometric interpretation of multi-band, NON-alpha images ?", by Ed Grissom
1998.09.22 14:51 "Large images (>2gb & >4gb)", by Ed Grissom
1998.09.22 14:52 "Sparse images (uninstantiated tiles/strips)", by Ed Grissom
1998.09.22 14:52 "Transparent pixel value (no transparency mask)", by Ed Grissom

1998.09.22 14:52 "Sparse images (uninstantiated tiles/strips)", by Ed Grissom

This message is one of a series of messages with questions about advanced raster topics and TIFF. See the message entitled "Tiff Questions - TIFF 7.0 ?" for more info.

Some workflows we do with raster imagery include making measurements from certain known, isolated points on the image called fiducials. None of the other imagery is necessary, but the fiducials must be in the "proper" place in the file for accurate measurements. Some of these images can be quite large (see message entitled "Large images (>2gb & >4gb)") and can be quite slow to load.

Our old raster format allowed the concept of "uninstantiated" or "solid-color" tiles. With this idea, tiles that have no raster data or have a constant pixel value can be stored with a special value in the tilemap that indicates a solid color. No disk space is taken up with actual tile data. (Typically the application or the raster i/o layer will "instantiate" these tiles when necessary for viewing or converting to other formats).

This feature allowed us to create very small versions of very large files containing only the tiles around each fiducial point. Measurements could be made from this "sparse" image very rapidly because there was very little raster data to deal with. Several steps in the workflow might only use the sparse image for measurements. Later, the measurements could be applied to the larger image because the sparse image had identical geometry.

This feature is sadly lacking in TIFF, and is explicitly prevented by such statements as:

    "Point to real data. All strip offsets must reference valid
     locations. (It is not legal to use an offset of 0 to mean something
     special.) "

which prevents us from using some special value in the tilemap, and

    "No Duplicate Pointers. No data should be referenced from more than one
    place. TIFF readers and editors are under no obligation to detect this
    condition and handle it properly. This would not be a problem if TIFF
    files were read-only entities, but they are not. This warning covers
    both TIFF field value offsets and fields that are defined as offsets,
    such as StripOffsets.

which prevents us from allocating a single solid color tile and referencing it from multiple tilemap locations.

Is there any chance that some feature like this could be added to TIFF? Perhaps in 7.0 or in a new Tech. Note?

My idea would be to have a separate tag that points to a list of "default" colors for each tile, and in the regular tilemap, an offset of zero would mean "look up the color of the whole tile in the separate tag"

The "size" of the default colors would be tied to the samples_per_pixel value so that any bit-depth image could have valid "solid-color" tiles of any valid color for that bit depth.

ed grissom