AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2000.04.14 18:01 "tiff with jpeg (unknown tag 33918)", by acatch
2000.04.16 20:53 "RE: tiff with jpeg (unknown tag 33918)", by Ed Grissom
2000.04.16 22:05 "RE: tiff with jpeg (unknown tag 33918)", by Ed Grissom
2000.04.17 00:03 "libtiff crash with tiled jpeg (was: unknown tag 33918)", by Tom Lane
2000.04.17 12:22 "RE: libtiff crash with tiled jpeg (was: unknown tag 33918)", by Ed Grissom
2000.04.17 15:04 "Re: libtiff crash with tiled jpeg (was: unknown tag 33918)", by Tom Lane

2000.04.17 12:22 "RE: libtiff crash with tiled jpeg (was: unknown tag 33918)", by Ed Grissom

In a previous message, Tom said:

   This jogged my memory a little bit. I think I fixed the problem in

> my private copy a long time ago,... Try the attached patch and see if > it helps.

I still get the crash in the same place with the patch in place. This patch does seem like it will take care of the fiddling I had to do for the grayscale case.

While stepping thru in the debugger, I noticed something that may have a bearing on the problem. It appears that Intergraph software and tiffcp (when _not_ using the :r: jpeg option) create files that follow the minimum spec in TTN2. That is,

        We recommend that RGB source data be converted to YCbCr for best
        compression results. Other source data colorspaces should probably
        be left alone. Minimal readers need not support JPEG images with
        colorspaces other than YCbCr and grayscale
(PhotometricInterpretation
        = 6 or 1).

        A minimal reader also need not support JPEG YCbCr images with
        nondefault values of YCbCrCoefficients or YCbCrPositioning, nor with

        values of ReferenceBlackWhite other than [0,255,128,255,128,255].
        (These values correspond to the RGB<=>YCbCr conversion specified by
        JFIF, which is widely implemented in JPEG codecs.)

In other words, these files have a TIFF Photometric interpretation of YCbCr, and the JPEG data is also YCbCr.

Tifcp, however is not equipped to do general colorspace conversion. There is no option on the tifcp command line to create a RGB image from a YCbCr image. Thus, if you try to create a uncompressed file from an Intergraph JPEG, or a defaulted tifcp JPEG, tifcp will try to create a uncompressed YCbCr image. Since the default for YCbCr images is subsampled, TIFFVTileSize only allocates enough space for the subsampled components. tiffcp blindly tries to copy an unsubsampled amount of data, and crashes when it walks off the end of the buffer allocated in TIFFVTileSize.

Fails in second tifcp:
======================
tifcp [tile/strip options] -c jpeg uncompRGB.tif YCbCrJPEG.tif
tifcp [tile/strip & compression options] YCbCrJPEG.tif output.tif

Works (note :r: JPEG option):

==============================
tifcp [tile/strip options] -c jpeg:r: uncompRGB.tif RGBJPEG.tif
tifcp [tile/strip & compression options] RGBJPEG.tif output.tif

I think that there are two problems here. One is that tifcp is not capable of doing general colorspace conversions, and the second is that it does not correctly deal with subsampled YCbCr images on INPUT.

Note that there are very good reasons for using YCbCr in JPEG compression. My tiny (6Meg) example file was 195K in YCbCr mode, 594K in RGB mode - with no visible difference in quality. Since we have customers that are creating images up near the FORTY Gigabyte range (uncompressed), we need every bit of compression we can get to stay under the 4GB limit of TIFF.

--
ed grissom
egrissom@ziimaging.com