TIFF and LibTiff Mail List Archive


1999.08.21 02:27 "This TIFF *is* bad. Why?", by Kevin D. Quitt
1999.08.22 17:07 "Re: This TIFF *is* bad. Why?", by Helge Blischke

1999.08.22 17:07 "Re: This TIFF *is* bad. Why?", by Helge Blischke

OK, this time for sure. The image is slightly ill. It displays properly, but it's the only image I've ever seen that when expanded and recompressed by libTIFF has completely different image data (with all parameters the same). If the data is placed into a PostScript document GCView won't even show it. If I put the recompressed data into the document instead, it displays and prints properly.

I'm telling the user that the TIFF is bad and that the vendor should be notified. I've also added an option that forces the program to expand and compress the image for use, so printing continues

But what is wrong with the TIFF? Or what am I (and PostScript) missing?

There is nothing wrong with this image. But it is written with the fill order tag set to 2, which is discouraged by the TIFF spec (see page 32 of the spec).

The IFD contains the following tags (default values honored):

/ImageLength 1526
/RowsPerStrip 1526
/ImageWidth 2558
/StripByteCounts [29206]
/T4Options 0
/T6Options 0
/FillOrder 2
/ResolutionUnit 2
/Predictor 1
/XResolution 300.0
/YResolution 300.0
/PlanarConfiguration 1
/Software (ScanFix\(TM\) Enhanced)
/StripOffsets [276]
/BitsPerSample [1]
/Orientation 1
/Compression 4
/DirectFileAccess true
/PhotometricInterpretation 0
/NewSubfileType 0
/SamplesPerPixel 1

If you decompress anbd recompress the image using libtiff and do NOT explicitely specify the fill order tag, it is obvious that the recompressed image data are different (I don't know if libtiff even supports writing images with fill order 2). Moreover, libtiff uses the machine's byte ordering scheme by default, i.e. if you process the image on a big-endian machine, the output will be different, as the original image has been created in little-endian format.