Received: by cthulhu.engr.sgi.com (941129.SGI.8.6.9/911001.SGI)
	for tiff-list id OAA18883; Fri, 16 Dec 1994 14:06:13 -0800
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (941129.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id OAA18876; Fri, 16 Dec 1994 14:06:06 -0800
Received: from digibd.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.com> id OAA04443; Fri, 16 Dec 1994 14:06:03 -0800
Received: by digibd.com (5.65/DBI-1.19)
	id AA20918; Fri, 16 Dec 94 16:04:20 -0600
From: rick@digibd.com (Rick Richardson)
Message-Id: <9412162204.AA20918@digibd.com>
Subject: Re: JBIG compression
To: kg@mykonos.rc.rit.edu (Kyriakos Georgiou)
Date: Fri, 16 Dec 1994 16:04:19 -0600 (CST)
Cc: sam@cthulhu.engr.sgi.com, tiff@sgi.sgi.com
In-Reply-To: <m0rIjmt-0007zYC@mykonos.rc.rit.edu> from "Kyriakos Georgiou" at Dec 16, 94 04:02:03 pm
X-Mailer: ELM [version 2.4 PL16]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1830      
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

Kyriakos Georgiou writes...
> 
> In response to Sam's comments:
> 
> >     Also, can the current libtiff G4 decompression implementation be
> >     improved ? What sort of improvements can be expected ?
> > 
> > What's wrong with the current implementation?
> 
> The current implementation is fine, but.. I have in my hands a commercial
> product (no source) that does decompression in noticable less time.
> That suggests that there are faster ways to decompress G4 in software,
> alas my question.

I cannot speak for the G4 decompression in libtiff, but I can vouch for the
fact that the libtiff G3 decompression is not as fast as at least my own
implementation.  However, I am not at liberty to provide the source code
since it belongs to my employer.

In my experience with G3, I found the fastest way was to completely unroll
the decompression.  I tried numerous different 'elegant' algorithmic
approaches over a period of about 3 years and discovered that the simple
brute force unrolled approach was always fastest.  The decoder itself is
something like 700 lines of nested C language if-else statements.

I did not write those 700 lines, though.  Instead, I wrote a program that
wrote those lines for me.  From time to time, I've been tempted to
change the decoder-generator program to output assembler instead of
C code.  I think that would ultimately be the fastest possible
implementation for any particular architecture (with the exception
of a full lookup table which takes up an impractical amount of RAM
on typical machines available today).

-- 
Rick Richardson	       Senior Staff Engineer   Visit my WWW home page:
DigiBoard APD	       Email: rick@digibd.com  http://www.digibd.com/people/rick
6801 Shady Oak Rd.     Fax:   (612) 947-1129   
Eden Prarie, MN 55344  Tel:   (612) 947-1111   <standard disclaimer>

