Path: utzoo!attcan!telly!nebulus!druid!darcy
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Newsgroups: comp.graphics
Subject: Re: Color Picking
Message-ID: <1989Dec15.133220.16043@druid.uucp>
Date: 15 Dec 89 13:32:20 GMT
References: <2241@cs-spool.calgary.UUCP>
Reply-To: darcy@druid.UUCP (D'Arcy J.M. Cain)
Organization: D'Arcy Cain Consulting, West Hill, Ontario
Lines: 27

In article <2241@cs-spool.calgary.UUCP> datta@cs-sun-fsb.UUCP (Slarti) writes:
>
>What I would like to do is load in a color graphics format that is stored
>with 24 bit planes and display it on an 8 bit device.  This in itself is not
>difficult, but what I need is a method of choosing 256 colors that can best
>be used to represent the image, without dithering or the like.  I can get
I wrote two different programs to do this.  The first simply did straight bit
shifting to get 24 bits to 8.

The other method was very slow but was able to get closer. I built a pallete
in memory by scanning the 24 bit image for colours.  If I passed 256 colours
then I reduced the colour resolution of one of the elements (blue first, then
green, then red then blue again ...) Eventually you wound up with the best
256 colours (actually a little less usually) that describe the image.  Just
a quick and dirty shot at the problem but it seemed to work.  In fact every
time I tried to optimize it, it took longer but was not as good a result.

The biggest problem with that approach is the length of time it took.  Of
course that would depend on the type of image.  I was working on 1024X1024
digitized photographs.


-- 
D'Arcy J.M. Cain (darcy@druid)     |   Thank goodness we don't get all 
D'Arcy Cain Consulting             |   the government we pay for.
West Hill, Ontario, Canada         |
No disclaimers.  I agree with me   |