Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!atrp.mit.edu!ashok
From: ashok@atrp.mit.edu (Ashok C. Popat)
Newsgroups: comp.graphics
Subject: Re: Compression of multi-bit images
Message-ID: <1990Jun7.114905.1714@athena.mit.edu>
Date: 7 Jun 90 11:49:05 GMT
References: <8099@b11.ingr.com> <SPENCER.90Jun4170821@spline.eecs.umich.edu>
Sender: news@athena.mit.edu (News system)
Reply-To: ashok@atrp.mit.edu (Ashok C. Popat)
Organization: MIT
Lines: 22

In article <SPENCER.90Jun4170821@spline.eecs.umich.edu> spencer@eecs.umich.edu (Spencer W. Thomas) writes:
>Lossless methods:
>
>Simple Huffman (adaptive or otherwise (the Unix 'pack' program) may do
>well if the pixel intensity (consider R,G,B values separately)
>histogram is not flat, even on scanned images.  Arithmetic coding will
>do better, but is harder to do.

Among arithmetic codes, those designed for a two-letter source
alphabet have received the most attention (for example, the Q-coder
has been talked about a lot recently).  Although it is possible to
encode an arbitrary source with a binary arithmetic code, it is not
the right thing to do for a bunch of reasons.  The right thing to do
in most cases is to use an arithmetic code that handles a multi-letter
source alphabet directly.  The basic principles of such a code are
simple but the details are a little complicated.  I describe the
details of a suitable arithmetic code in chapt. 3 of my SM thesis,
which I'll make available in (Postscript form) via anonymous ftp
somewhere if enough people are interested.  Let me
(ashok@atrp.mit.edu) know if you're interested.

Ashok Chhabedia Popat   Swiss Federal Institute of Technology,  Lausanne