Received: from [207.176.88.85] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Sun, 17 Dec 2000 20:19:51 -0500
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id TAA13498;
	Sun, 17 Dec 2000 19:34:35 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Sun, 17 Dec 2000 19:30:21 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id TAA13110
	for tiff-outgoing; Sun, 17 Dec 2000 19:30:21 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from gw.errno.com (node-d1d4bd7a.powerinter.net [209.212.189.122])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id TAA13107
	for <tiff@olympiakos.com>; Sun, 17 Dec 2000 19:30:18 -0500
Received: from melange (melange.errno.com [209.212.166.36])
	by gw.errno.com (8.9.0/8.9.0) with SMTP id QAA29132;
	Sun, 17 Dec 2000 16:30:02 -0800 (PST)
Message-ID: <01c901c06889$a939ce40$24a6d4d1@melange>
From: "Sam Leffler" <sam@errno.com>
To: "Joris Van Damme" <as.van.damme.joris@planetinternet.be>,
        "Christian Bednarek" <cbednare@t-online.de>,
        "TIFF Mailing List" <tiff@olympiakos.com>
References: <Pine.LNX.4.21.0012151034530.7495-100000@marvin.eazy> <3A3D4F2E.7211852B@planetinternet.be>
Subject: Re: Stripes in thumbnail
Date: Sun, 17 Dec 2000 16:29:43 -0800
Organization: Errno Consulting
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: owner-tiff@olympiakos.com

> LibTiff fax decompression has been reported to behave differently from
> other decompressors like eg the one in Photoshop. My guess is that some
> scanlines in the original g4 tiff(s) cannot be correctly interpretted by
> LibTiff, and are simply (partially) skipped, leaving a (partially) blank
> line. Warning and error behaviour of the g3/g4 decompressors has been
> reported to be imperfect, so it's even possible you don't even get a
> warning about this, I guess...

The G3 and G4 codecs in the library should follow the published specs; if
they don't please provide an example image where they don't.  Suggesting
that they behave differently than other codecs (e.g. Photoshop) is nonsense.

FWIW, these codecs haven't changed in any material way in probably 5 or 6
years (the last change I can recall was to support images wider than 64K
pixels--i.e. changing some 16-bit counters to 32-bit). The library
(including G3+G4 support) has been around for >10 years.

As to error and warning behaviour; again please be specific if you've
encountered a problem.  The G4 decoder cannot resynchronize on scanline
boundaries so it treats any decoding error as "fatal" and does not attempt
to continue decoding a scanline, strip, or tile.  The G3 decoder can
resynchronize when EOL markers are present and tries to since many
G3-encoded images are obtained from fax transmissions where single bit
errors may be present and aborting the decoding is typically not the desired
behaviour. In all cases the library error and/or warning handlers are
invoked when decoding fails for some reason.  I don't recall exactly which
handler is invoked under which conditions; check the source code.

    SAm


