2000.04.16 20:53 "RE: tiff with jpeg (unknown tag 33918)", by Ed Grissom

I have several tiff images in tiff/jpeg format created using intergraph software. When trying to decompress the files to uncompressed tiff using tiffcp I get a unknown tag error 33918. It appears Intergraph owns this tag and uses it to store some info required for decompression. Anyone know what info is asscoiated with this tag.

Alex -

The information contained in tag 33918 can be quite varied. However, it does not contain info that is required for decompressing the imagery. It appears that your problems are caused by a bug in either tiffcp, or in LibTIFF itself.

Previous versions of tiffcp have had some problems with tiled imagery, which most Intergraph images are, and it still seems to have some problems with tiled JPEG imagery. These JPEG problems may exist in untiled JPEG as well, I did not test that.

++++++++++++++++++++++++++++++++

Here is what I did:

First of all, I am still on version 3.4beta037 (with some mods that have been posted to the list, but not all).

I took an uncompressed RGB TIFF, and using tiffcp, I created a tiled (128x128) JPEG compressed image. This file displays fine in 3rdparty displayers as well as with Intergraph software.

Next, I took that tiffcp-created RGB (actually YCbCr) JPEG image, and tried to create a new image. Tiffcp crashes with an unhandled exception. Note that Intergraph created files are totally out of the picture here.

It does not matter what compression or tilesize (including none) is used on the output image. Tiffcp crashes because the buffer that is decompressed from the input JPEG is not big enough. It should be 49152 bytes( 128x128x3), but inexplicably is about half that. I suspect that the problem is either in tiffcp itself, or in the JPEG-LibTIFF interface while setting up LibJPEG to decompress or upsample properly.

Perhaps the problem is in the default subsampling. Neither the tiffcp-created images nor the Intergraph-created images have any YCbCr tags, so the default subsampling of [2,2] is supposed to be used. I am no expert at reading LibTIFF/LibJPEG code, but it seemed to me that tiffcp was defaulting to something else when reading this file.

++++++++++++++++++++++++++++++++

I was able to convert an Intergraph-created _Greyscale_ TIFF JPEG using tiffcp after I played around with the default setting of "jpegcolormode" in tiffcp.c. I remember that "jpegcolormode" was the subject of some of the fixes posted to the list since 3.4beta037, but I am not sure if I have the latest or not.

I could not convert an Intergraph-created nor tiffcp-created RGB (YCbCr) TIFF JPEG using tiffcp at all. No amount of messing with "jpegcolormode" helped.

I'll move up to the latest version of LibTIFF and see if that helps...

Here is the lowdown on tag 33918. The Intergraph Raster File Format had a variably sized area available for different Intergraph applications to write application specific information to the raster file. This application specific info is stored in "packets", each of which has a 4-byte identifying number at the beginning, followed by a 4-byte length field, followed by the data. With this setup, applications could look thru the application specific area and find packets that they knew how to handle, and could skip over ones that they did not know how to handle.

When Intergraph applications began using TIFF files for general image interchange, we used one of our private tags to point to an area of the TIFF file where we stored our collection of packets. So, depending on the application that created the file, there may be a variety of different info stored there. Probably the most common information stored there is a Transformation matrix that can tie the raster to a MicroStation design file.

According to the TIFF spec,

"TIFF readers must be prepared to encounter fields other than those
   required in TIFF files. ....TIFF readers must also be prepared to
   encounter and ignore private fields not described in the TIFF
   specification.

Fortunately, LibTIFF follows the spec and does not refuse to read the file due to this tag. I think that it does put up a warning message box when it encounters the tag. This is unfortunate, and is the cause for many problem reports we get. Some applications built on top of LibTIFF (ACDSee for one) have a custom warning handler that just writes to "OutputDebugString()" instead of popping up a message box.

ed grissom
egrissom@ziimaging.com (formerly egrissom@intergraph.com)