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