Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!venera.isi.edu!raveling
From: raveling@isi.edu (Paul Raveling)
Newsgroups: comp.sys.ibm.pc
Subject: Re: GIF File Format
Message-ID: <13317@venera.isi.edu>
Date: 8 May 90 16:41:28 GMT
References: <843@umt.UUCP> <ROSEN.90May3192224@polar.bu.edu>
Sender: news@venera.isi.edu
Reply-To: raveling@isi.edu (Paul Raveling)
Organization: USC Information Sciences Institute
Lines: 37


In article <ROSEN.90May3192224@polar.bu.edu>, rosen@polar.bu.edu (David
B. Rosen) writes:
> I don't have the GIF Format, but I know why it's smaller: it's
> compressed! As I understand it, the GIF file format has LZW (Lempel
> Ziv Welch) compression (like unix compress) built in. If you use a
> standard compression utility on your TARGA-16 files, they may end up
> about the same size as the GIF file...

	That's true.  When the Img Software Set writes an image file
	by default it pipes it through compress; the resulting file
	is about the same size as a corresponding GIF file.  Most
	are very slightly smaller, probably because the entire file
	(header included) is compressed.  I believe Jef Poskanzer
	has reported similar results for the PBM software.

	I like the idea of compressing the entire file rather than
	having compression/decompression logic embedded in software
	that reads or writes the files for 2 reasons:

	    1.  When the entire file is compressed, it's possible
		to use existing tools to manipulate it (for example,
		"zcat file | favorite_dump_utility), rather than
		having to write specialized tools.

	    2.  Software to read and write the files is simpler.

	The ideal would probably be to have the OS disk i/o functions
	automatically do compression/decompression.  Best would be
	to add a hardware assist -- it shouldn't take much silicon
	to do this EXTREMELY fast and to make that process invisible
	to even OS software.


----------------
Paul Raveling
Raveling@isi.edu