Status: Read
Received: from [207.176.88.85] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Fri, 17 Nov 2000 03:26:38 -0500
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id DAA01825;
	Fri, 17 Nov 2000 03:20:00 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Fri, 17 Nov 2000 03:11:14 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id DAA01536
	for tiff-outgoing; Fri, 17 Nov 2000 03:10:57 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from imps0054.us.dg.com (imps0054.us.dg.com [128.221.44.54])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id DAA01533
	for <tiff@olympiakos.com>; Fri, 17 Nov 2000 03:10:55 -0500
Received: by imps0054.us.dg.com with Internet Mail Service (5.5.2650.21)
	id <WN7Y2FZV>; Fri, 17 Nov 2000 03:10:41 -0500
Message-ID: <FD7E8A8A5060D1119AEF0000F806A97F096E0755@imps0024>
From: "Myers, Randall" <rmyers@dgexchange.dg.com>
To: "'Joris Van Damme'" <as.van.damme.joris@planetinternet.be>,
        TIFF Mailing List <tiff@olympiakos.com>
Subject: RE: Has something changed with error detection in group4 data?
Date: Fri, 17 Nov 2000 03:10:39 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Sender: owner-tiff@olympiakos.com

>> "Myers, Randall" wrote:
>> the worst
>> case (no errors detected when they clearly exist)

>Then Joris Van Damme wrote:
>
> Is this the worst case?...
> ... Therefore, in my opinion, if the
> library can go on decoding the image, a warning should be emitted
> instead of an error...

I'm sorry, I was not clear.  I was not actually referring to
a value returned by a library function (which, as you point out,
has never revealed decoding errors which the library detects
but doesn't stop for).  I use the TIFFErrorHandler callbacks
to detect what I referred to as "errors".  Furthermore, I am
in fact relying on warnings rather than error reports.  I had
not made this distinction because I treat them equally for my
purposes, but it is actually true that the conditions I most
often encounter end up generating a warning rather than an error.
And of course, by "worst case" I meant that case which was worst
for me - no indication rather than just fewer than normal
indications of a problem condition.

So to clarify:  the behavior that has changed is that the library
reports fewer (or no) "Fax4Decode" warnings in revisions from
3.4beta036 forward than it did in previous revisions, at least for
a class of images I have trouble with.

And since my previous posting, I think I have determined that a
relevant code change was made to tif_fax3.h in 3.4beta036:

# diff tiff-v3.4beta035/libtiff/tif_fax3.h \
>      tiff-v3.4beta036/libtiff/tif_fax3.h
1c1
< /* $Header: /usr/people/sam/tiff/libtiff/RCS/tif_fax3.h,v 1.31 1996/06/04 19:0
4:41 sam Exp $ */
---
> /* $Id: tif_fax3.h,v 1.33 1996/08/22 18:17:39 sam Exp $ */
510,514c510,516
<       /* expect a final V0 */                                         \
<       NeedBits8(1,eof2d);                                             \
<       if (!GetBits(1))                                                \
<           goto badMain2d;                                             \
<       ClrBits(1);                                                     \
---
>       if (RunLength + a0 < lastx) {                                   \
>           /* expect a final V0 */                                     \
>           NeedBits8(1,eof2d);                                         \
>           if (!GetBits(1))                                            \
>               goto badMain2d;                                         \
>           ClrBits(1);                                                 \
>       }                                                               \

As an experiment, I substituted the older code fragment in the current
version of libtiff and found this reinstated the decode warning behavior
that I am used to seeing.

I don't know what condition this change was intended to address, but since
I've never relied on it, I feel pretty safe in reverting to the old code
as a temporary or custom solution to my particular problem.  Does anyone
know what I'd be giving up?

Regards,

Randy Myers
