Xref: utzoo comp.binaries.ibm.pc.d:112 comp.sources.d:2027
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!pyramid!octopus!pete
From: pete@octopus.UUCP (Pete Holzmann)
Newsgroups: comp.binaries.ibm.pc.d,comp.sources.d
Subject: Don't be 'sure' if you aren't! Re: Standard for file transmission
Message-ID: <213@octopus.UUCP>
Date: 5 May 88 03:45:55 GMT
References: <299@cullsj.UUCP>
Reply-To: pete@octopus.UUCP (Pete Holzmann)
Organization: Octopus Enterprises, Cupertino CA
Lines: 25
Keywords: compression, archive, UUCP
Summary: Compress works great on graphics

In article <299@cullsj.UUCP> jeff@cullsj.UUCP (Jeffrey C. Fried) writes:
>
>   I stand corrected.  Since Lem-Ziv was DESIGNED for text compression, and
>the authors do not mention its use for binaries, i never considered using it.
>I tried it on an executable under UNIX and obtained a good reduction, for 
>reasons which are not apparent.  I'm sure that there are cases where this does
				  ^^^^^^^^
>not work (like graphics files), but it does appear to work , and in this case
	   ^^^^^^^^^^^^^^^^^^^
>better than the current version of ARITH.

Amaze your friends! Confound your enemies! Take a big TARGA graphics file
[24 bit data] and compress it to 10% or less of its original size if it
has much evenly-colored image area. Compress it by at least a *little*
(e.g. 10+%) even if it is a very busy image. Works as well as other
single-image compression techniques I've seen [assuming you want the
compressed output in reasonable time]. All courtesy of the LZW algorithm!

I wonder if L, Z and W are planning on suing everybody for infringing on
their copyright :-).
-- 
  OOO   __| ___      Peter Holzmann, Octopus Enterprises
 OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
  OOOOO \___/        UUCP: {hpda,pyramid}!octopus!pete
___| \_____          Phone: 408/996-7746