LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2000
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
Thread
2000.04.16 20:53 "Re: tiff with jpeg (unknown tag 33918)", by Ed Grissom
In a previous message, Alex said:
> 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)