AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
August 1999

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



Valid HTML 4.01!



Thread

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

Kevin D. Quitt wrote:
> 
> OK, this time for sure.  The image ftp://ftp.quitt.net/TIFF/00001901.tif 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.

Helge

-- 
H.Blischke@srz-berlin.de
H.Blischke@srz-berlin.com
H.Blischke@acm.org