Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.graphics
Subject: Re: boring group
Message-ID: <5377@brl-tgr.ARPA>
Date: Thu, 18-Oct-84 14:53:12 EDT
Article-I.D.: brl-tgr.5377
Posted: Thu Oct 18 14:53:12 1984
Date-Received: Fri, 19-Oct-84 02:04:57 EDT
References: <1556@ucla-cs.ARPA> <1206@utah-gr.UUCP> <1651@ucla-cs.ARPA>
Organization: Ballistic Research Lab
Lines: 18

> So, a question: do you actually have the disk storage to save lots of 24
> bit images?

The fellows at Utah will probably also respond, but just in case:

Typical frame buffer images are quite amenable to various data compression
schemes; a typical one is Run-Length Encoding (at BRL, we picked up on what
Utah had done for this and store all our frame buffer images as RLE files).
I am convinced that simple RLE of R,G,B components (which shrinks images
to maybe 30% of their original size) is nowhere near optimal encoding so
far as size is concerned, but it has that advantage of being sufficiently
fast that the time taken to unencode and display such a file is acceptable.
I did the simple experiment of applying Huffman encoding (byte-wise, using
"pack") on already RLE-encoded files and got a nontrivial amount of extra
compression, although unpacking time was no longer negligible.

I would like to hear about image file shrinking schemes that unpack
quickly and have high compression.