Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site turtlevax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!zehntel!dual!amd!turtlevax!ken From: ken@turtlevax.UUCP (Ken Turkowski) Newsgroups: net.graphics Subject: Re: Allocating colors Message-ID: <560@turtlevax.UUCP> Date: Mon, 15-Oct-84 04:04:55 EDT Article-I.D.: turtleva.560 Posted: Mon Oct 15 04:04:55 1984 Date-Received: Tue, 16-Oct-84 06:48:48 EDT References: <1556@ucla-cs.ARPA> Organization: CADLINC, Inc. @ Palo Alto, CA Lines: 24 > <==== yum yum ====> > 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? Allocating colors in the color table is a quantization problem. Unless you know something about the probability distribution of colors, you'll end up with a uniformly quantized color space. For the best quantization, you should really generate 24-bit (or at least 15-bit) pixels for the entire picture, then cluster populations and pick representative values. Paul Heckbert from NYIT published an algorithm for this in the SIGGRAPH proceedings of several years past, and a recent (<1yr) issue of IEEE CG&A uses the novel approach of Peano-curve scanning to form clusters. -- Ken Turkowski @ CADLINC, Palo Alto, CA UUCP: {amd,decwrl,flairvax,nsc}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA