Return-Path: owner-tiff@olympiakos.com
Return-Path: <owner-tiff@olympiakos.com>
Received: from nataly.at1895.spb.edu (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.4/8.12.4/Debian-4) with ESMTP id g6O8GTxd015112
	for <dron@at1895.spb.edu>; Wed, 24 Jul 2002 12:16:29 +0400
Received: from olympiakos.com (uucp@localhost)
	by nataly.at1895.spb.edu (8.12.4/8.12.4/Debian-4) with UUCP id g6O8GTpJ015110
	for dron@at1895.spb.edu; Wed, 24 Jul 2002 12:16:29 +0400
Received: from knot.pu.ru (knot.pu.ru [193.124.85.214] (may be forged))
	by wg.pu.ru (8.9.1a/8.9.1) with ESMTP id HAA03408
	for <dron@at1895.spb.edu>; Wed, 24 Jul 2002 07:57:35 GMT
Received: from gate7.olympiakos.com (sdsl-64-32-199-150.dsl.iad.megapath.net [64.32.199.150])
	by knot.pu.ru (8.9.3/8.9.0) with ESMTP id LAA12125
	for <dron@at1895.spb.edu>; Wed, 24 Jul 2002 11:57:34 +0400 (MSD)
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id DAA32542;
	Wed, 24 Jul 2002 03:54:47 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Wed, 24 Jul 2002 03:46:41 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id DAA32472
	for tiff-outgoing; Wed, 24 Jul 2002 03:46:40 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from lilly.ping.de (IDENT:qmailr@lilly.ping.de [62.72.90.2])
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id DAA32469
	for <tiff@olympiakos.com>; Wed, 24 Jul 2002 03:46:39 -0400
Received: (qmail 14418 invoked by uid 10); 24 Jul 2002 07:46:37 -0000
Received: from cliwe.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 24 Jul 2002 07:46:37 -0000
Received: (qmail 13767 invoked by uid 500); 24 Jul 2002 07:46:10 -0000
To: faxguy@howardsilvan.com
Cc: tiff@olympiakos.com
Subject: Re: CCITT Group 4 assistence needed for HylaFAX
References: <20020723225031.GA3059@bilbo>
From: fdc@cliwe.ping.de (Frank D. Cringle)
Date: 24 Jul 2002 09:46:10 +0200
In-Reply-To: <20020723225031.GA3059@bilbo>
Message-ID: <m3lm81y3el.fsf@sabre.ping.de>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-tiff@olympiakos.com
Precedence: bulk
Status: RO
Content-Length: 2230
Lines: 42

Lee Howard <faxguy@howardsilvan.com> writes:
> ...
> I'm needing some help with getting HylaFAX to support MMR-encoded
> (Group 4) faxes.  I've got a nearly complete patch for HylaFAX which
> does this, but I've run into a couple of snags which are rooted in
> code incompatibility with the differences between Group 3 and Group 4
> TIFF image data.  As I'm not TIFF-savvy, I'm seeking for help on this.
> ...
> However, even if you don't have this kind of time, I wouldn't mind
> some general outlines on how these two procedures should be altered
> for Group 4 faxes (i.e., how to count lines and how to image a tagline
> on top of an existing image).

Disclaimer: I am not familiar with HylaFAX, so I may be making some
wrong assumptions in that area.  As I understand it, when HylaFAX
receives a G3 fax, the modem reports the number of lines in the fax in
a status report.  In practice, G3 faxes are often damaged in
transmission so HylaFAX counts the number of lines actually received
and records that value in the tiff header instead of (or as well as?) 
the expected value.

A damaged G4 fax is useless, or at least it can only be interpreted up
to the first error.  So we must assume an error free (or error
correcting) channel for transmission of G4 faxes.  In that case the
sender should be able to tell the receiver how many lines are in the
fax.  That would make counting after reception redundant.

If you really need to count the lines in a G4 image, you need to know
the precise width and then run through all the data, interpreting each
code bitstring as you go.

As to adding or replacing initial lines, the easiest way would be to
expand the image into a bitmap, replace the lines and then re-encode
the image.  Doing it more efficiently by just replacing the relevant
part of the raw data should be possible but rather fiddly.  I don't
recall off hand whether G4 allows padding bits to be inserted, to
avoid repacking all the bytes after the transition from new to old
data.

-- 
Frank Cringle,      fdc@cliwe.ping.de
voice: (+49 7745) 928759; fax: 928761

To subscribe or unsubscribe email tiff-request@olympiakos.com with subscribe
or unsubscribe in the email body.  Libtiff home page: http://www.libtiff.org

