Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.graphics
Subject: Re: boring group
Message-ID: <1206@utah-gr.UUCP>
Date: Fri, 12-Oct-84 12:13:21 EDT
Article-I.D.: utah-gr.1206
Posted: Fri Oct 12 12:13:21 1984
Date-Received: Sat, 13-Oct-84 06:43:55 EDT
References: <1556@ucla-cs.ARPA>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: Univ of Utah CS Dept
Lines: 21

In article <1556@ucla-cs.ARPA> rick@ucla-cs.UUCP writes:
>I have been generating color (that's colour for you people in Canada) images
>using an 8 bit color lookup table. However, I have been unable to find any
>good algorithms (or even bad ones, although I have invented several TERRIBLE
>ones) to allocate my precious 256 entries in the color table. Of course it
>would be a lot easier to generate the picture completely in 24 bits but then
>what is the point in using a scanline algorithm for rendering? So, does anyone
>have a way to allocate color table entries while a program is running with no
>'a priori' knowledge of what the picture looks like?

A student here did a pretty good dithering algorithm for taking a full
color (i.e. 24 bit) image down to 8 bits.  It uses a pre-allocated fixed
color table (in fact, uses only 216 of the entries).  It looks pretty
good on a 512 display, and pretty fantastic on a 1k display (although
still not as good as really having 24 bits).  I could ask him if he
would mind if it got posted to the net.

(I don't understand the comment about 24 bits above - we do all our
scanline rendering in 24 bits (of course, we have 24 bit frame buffers).)

=Spencer