Return-Path: <owner-tiff@olympiakos.com>
Received: (from uucp@localhost)
	by smtp02.oce.nl (8.9.3/8.9.3) id IAA08959
	for rvdt@smtp02.oce.nl; Thu, 14 Oct 1999 08:41:57 +0200 (MET DST)
Received: (qmail 8958 invoked by uid 5); 14 Oct 1999 06:41:57 -0000
MBOX-Line: From uucp Thu Oct 14 08:41 MET 1999
>Received: from gate7.olympiakos.com (esp6016.nrl.navy.mil [132.250.206.16])
	by oce.nl (8.9.0/8.9.0) with ESMTP id IAA00415;
	Thu, 14 Oct 1999 08:32:37 +0200 (MET DST)
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id EAA03663;
	Thu, 14 Oct 1999 04:31:57 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Thu, 14 Oct 1999 04:31:47 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id EAA03650
	for tiff-outgoing; Thu, 14 Oct 1999 04:31:46 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id EAA03647
	for <tiff@olympiakos.com>; Thu, 14 Oct 1999 04:31:41 -0400
Received: from earthlink.net (pool0461.cvx1-bradley.dialup.earthlink.net [209.178.129.206])
	by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id XAA24868;
	Wed, 13 Oct 1999 23:31:14 -0700 (PDT)
Message-ID: <38054E95.D24650F@earthlink.net>
Date: Thu, 14 Oct 1999 03:31:33 +0000
From: Niles Ritter <ritter@earthlink.net>
X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Sam Ohzawa <fastio@fastio.com>
CC: tiff@olympiakos.com
Subject: Re: Bad G3 TIFF file or LIBTIFF bug?
References: <Pine.BSF.4.10.9910131726580.14754-100000@shell18.ba.best.com>
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@olympiakos.com
Content-Type: text/plain; charset=us-ascii

Sam Ohzawa wrote:

> Our customer has brought in a G3 TIFF file that libtiff
> has trouble decoding.  And I am stuck debugging through libtiff.
>
> Could you take a look at the file?:
> http://www.fastio.com/bad.tif
>
> (66kb)
>
> and determine what is at fault?

Yes.

>
>
> Actually, this is a 2-page TIFF file, and libtiff succeeds in
> decoding page 1, but fails on page 2.
>
> For example, "tiffsplit bad.tif" shows the error:
>
> TIFFReadRawStrip: bad.tif: Read error at scanline 4294967295; got 17843
> bytes, expected 48213.

Your error message is exactly right. The size of the file is 48461 bytes,
and a tiffdump reveals for the second image directory:

StripOffsets (273) LONG (4) 1<30618>
...
StripByteCounts (279) LONG (4) 1<48213>

so, if you go to offset 30618 in the file, you only have 17843 bytes
left in the file, contradicting the next line that the data for the (only)

strip in the image has 48213 bytes, just like the error message said.

The imaging for windows software has not had the best track
record for a TIFF implementation; in fact it sucks.  It has been known to
write bad noncompliant TIFF  (it does not use libtiff), and it wrote a
bad file in this case.  I think this was the one that used to write bogus
JPEG-TIFF files, but I could be confusing it with the Wang Imaging
product (unless they merged evil forces).

>
>
> Tiffdump does not show anthing unusual about the  tags.
>
> This file is viewable correctly by "Imaging for Windows Preview"
> made by Kodak for Microsoft on Win98.

I am willing to bet that the data is okay, but that the bogus software
wrote the wrong byte size (or didn't update the value after doing
the compression). In fact, I'll bet the code has a bogus hack that
someone put into IWP when they realized that their byte counts are wrong,
which simply ignores the byte count if it can get a full image out of the
data they do have.

The proof of this will be to hack the byte offset to 17843 and see if
libtiff can upack it. ...

[hack hack...]

Okay, I just hacked the bytes and both images come through
tiffsplit just fine.  The first image says "this is a first page", and
the second says "I received your fax!" and a bunch of other
stuff.    You may find a copy of the hacked file in

       http://home.earthlink.net/~ritter/tiff/good.tif

Run tiffdump and tiffsplit and see for yourself.

Like I said; the MS imaging package sucks.  I vaguely recall
being on the phone with them to try to convince their programmers
to do a better job, but they didn't seem to care (this was several years
ago).

I don't know if it's worth it to put yet another workaround in libtiff
to try to unpack less data than it is supposed to have or not.  My
preference would be for a lot of folks to harangue whoever owns
the blasted imaging thing now and tell them I said it *still* sucks.

--Niles.



