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