Status: Read
Received: from phillip.thumbsplus.com by phillip.thumbsplus.com (NTMail 3.02.11) with ESMTP id pcrews for <pcrews@cerious.com>; Tue, 3 Jun 1997 06:39:31 -0400
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id DAA14282; Tue, 3 Jun 1997 03:33:13 -0700
	env-from (owner-tiff@sgi.engr.sgi.com)
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA22894 for tiff-list; Tue, 3 Jun 1997 01:39:40 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA22876 for <tiff-relay@relay.engr.sgi.com>; Tue, 3 Jun 1997 01:39:37 -0700
Received: from hp00086.ina.de (hp00086.ina.de [159.51.6.8]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id BAA01014
	for <tiff@sgi.com>; Tue, 3 Jun 1997 01:39:34 -0700
	env-from (bartzkau@kou3.ina.de)
Received: from hp00363.kou3.ina.de (hp00363.ina.de)
	by hp00086.ina.de with ESMTP (1.37.109.18/INA-1.0-SER)
	id AA282947126; Tue, 3 Jun 1997 10:38:46 +0200
Received: from hp00244
	by kou3.ina.de with SMTP (8.7.1/INA-1.0)
	for hp00086
	id EAA21451; Tue, 3 Jun 1997 04:41:11 -0400 (EDT)
Message-Id: <3393D8A5.4E4A@kou3.ina.de>
Date: Tue, 03 Jun 1997 10:41:09 +0200
From: "Dr. Klaus Bartz" <bartzkau@kou3.ina.de>
X-Mailer: Mozilla 2.0 (X11; I; HP-UX B.10.20 9000/720)
Mime-Version: 1.0
To: Dieter Stueken <stueken@qgp.uni-muenster.de>
Cc: tiff@sgi.com
Subject: Re: CCITT Grp 4 decoder bug
References: <199706020839.KAA08387@qgp.uni-muenster.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@fddi-sgi.engr.sgi.com
Precedence: bulk

hello Dieter,
it is not a bug, it is a feature !

Do you have realy a real TIFF file with the compression format CCITT
t.6 
and the data coherence format untiled  ( striped is a problem
(but possible), because the expanded strip size is greater than 8K
bytes) 
bigger than 64 K pixel in one dimension  as input? Can I have it ( if
the
second dimension is big too and if it is a real image)?
Or do you want to create that images ? Then use tiles and you can go to
the
next problem of limitations. It is possible, that there are more
problems
than you want. You are going out of the 32 bit world.

In the last monthes there are some discussions related to limits
of tiflib / TIFF ( if needed I can forward that emails ).

For some years I have implemented a 32 bit encoder/decoder for TIFF G4
by my self with theoretical support up to 1 M * 1 M pixel ( tested up
to
210 K * 130 K pixel). Of course with tiles, 32 bit buffers, buffer
police,
scaling and rotation on a intermediaer code an so on. It works with 
32 MB RAM. 
But if I should look into that code, I hate that decision.
And the "simple" FaxG4 en/decoder of tiflib is faster as my en/decoder
:-(
( realy that coder is not so simple; I have no idea to speed it up). 
Most of our users have images up to DIN-A3 400 dpi, some up to DIN-A0
400 dpi
and one ore three up to ~ 60 K * 10 K pixel.

I am interested to discuss the problems ( I think outside this mailing
list).

Klaus Bartz


Dieter Stueken wrote:
> 
> When processing big FaxG4 coded TIFF-files I noticed, that the
> decoder algorithm fails for scanlines of >65k. The reason is an
> uint16 array to store the runlength encoded data. I changed all
> that to uint32 and it seems to work now. I wonder why nobody else
> ever got this problem before. Anyone interested in a patch?
> 
> Dieter Stueken.
> --
> Dieter Stueken, Inst. f. Kernphysik, WWU-Muenster
>    stueken@qgp.uni-muenster.de             stueken@conterra.de
>    http://qgp.uni-muenster.de/~stueken     http://www.conterra.de/
>    (0)251-83-334974                        (0)251-980-2027

-- 
-------------------------------------------------------------------
Dr. Klaus Bartz                                bartzkau@kou3.ina.de
COI GmbH / Abt. KOU3    Industriestr. 1-3    D-91072 Herzogenaurach
Tel: +49 (9132) 82-3433                        Fax: +49-9132-824959
