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.