Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!elroy!mahendo!jplgodo!wlbr!etn-rad!jru
From: jru@etn-rad.UUCP (John Unekis)
Newsgroups: comp.graphics
Subject: Re: Data Compression
Message-ID: <308@etn-rad.UUCP>
Date: Fri, 20-Nov-87 16:41:09 EST
Article-I.D.: etn-rad.308
Posted: Fri Nov 20 16:41:09 1987
Date-Received: Sun, 22-Nov-87 22:38:40 EST
References: <619@applix.UUCP> <305@etn-rad.UUCP> <3387@adobe.COM>
Reply-To: jru@etn-rad.UUCP (John Unekis)
Organization: Eaton Inc. IMSD, Westlake Village, CA
Lines: 12
Keywords: compression fonts

In article <3387@adobe.COM> greid@adobe.UUCP (Glenn Reid) writes:
>The way compression schemes work, in general, is to take N bits of data and
>represent the pattern in M bits (hopefully N > M)....
>But what if there were an ISO standard "table" of bitmaps, ...
As my wife always says-"Great minds run in the same gutters." This scheme is
very much like what the CCITT used for group III and IV compression . They
have a table of bit strings, each of which is unique and non-repeating. The
shortest bit strings are used to "encode" the statistically most common
run-lengths of bits. This scheme is called Huffman encoding. It achieves
terrific compression on one-bit-deep images, but it may produce negative
compression if the image is noisy, and it is not useful for 8-bit-deep
gray-scale images. It has been implemented in hardware in the AMD7970.