[comp.sys.amiga.tech] Color compression routines

raz@kilowatt.uucp (Raz- Berry) (04/26/89)

  Calling all GRAPHICS GURU's. I am in the process of adding the 
 ability of doing HAM pics' to iff2sun. Unfortunately I have very
 little idea on how to compress a color map. I need a basic flowchart
 on taking a 4096 color palette and converting it down to
 256. Initially I was thinking that:

 1) Sort the file by pixel color (emulating HAM mode of course).
    eg. how many reds? how many purples? how many puke greens?
 2) take the largest number of pixels per color, and assign them their
    very own color register (up to 256).
 3) take any remaining colors (if we have exceeded the 256 available colors)
    and perform the 'best fit' with the current palette.

  Assuming for the moment that this is the correct way to go, could some
 kind soul clue me in to the appropiate 'best fit' for a palette 
 algorithim?

  I am not real fond of the approach I have described above. If you have a
 better method PLEASE let me know.

  Ideas appreciated. I'll even consider a graphics reference book if you
 know of one.
-- 
Steve -Raz- Berry      Disclaimer: I didn't do nutin!
UUCP: sun!kilowatt!raz                    ARPA: raz%kilowatt.EBay@sun.com
"Fate, it protects little children, old women, and ships named Enterprize"

ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/27/89)

In article <33747@kilowatt.uucp> raz@kilowatt.uucp (Raz- Berry) writes:
> I need a basic flowchart
> on taking a 4096 color palette and converting it down to
> 256. Initially I was thinking that:
>
> 1) Sort the file by pixel color (emulating HAM mode of course).
>    eg. how many reds? how many purples? how many puke greens?
> 2) take the largest number of pixels per color, and assign them their
>    very own color register (up to 256).
> 3) take any remaining colors (if we have exceeded the 256 available colors)
>    and perform the 'best fit' with the current palette.
>
	Permit me to poke a hole in this.

	Suppose I have a simple HAM picture.  The left half of the screen is
various hues of purple, and the right half of the screen is various hues of
blue.  Separating these two fields is a vertical line, one pixel wide, that
is solid white.

	Now, if you were to do a histogram on this image, you'd probably
find the most popular 256 entries were hues of purple and blue, and white
would be right at the bottom of the list.  However, that white line is a
prominent feature, because of its contrast with the rest of the image.  So
picking colors for a reduced bitmap isn't all that simple.

	I had to attack similar problems when writing some internal tools
when we were developing Roger Rabbit.  I strongly recommend you get yourself
a book on image processing (something I should have done).

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
 \_ -_		Recumbent Bikes:	UUCP: pacbell > !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor

jmdavis@ihlpm.ATT.COM (Davis) (04/28/89)

First, you may want to post this to comp.graphics also. There
they have human factors types and references to the SIGGRAPH
journals where just your type of palette compression could
have been discussed in the past.

Second, I wouldn't weigh BLUE as heavily as I would RED and
GREEN. BLUE is harder for humans to see. This would have drastic
changes in both your most popular color algorithm and your best
fit algorigthm. Think about it, I would say that color (RGB) (332)
should be lumped together with  colors (333) and (331).

Third, I don't think .tech is the appro place for this (but I am
not sure, so I post here too). .tech is for technical Amiga stuff,
you have asked a technical graphics question, not dealing with amiga
system function calls, amiga system programming, etc.

-- 
----------------------------------------------------------------------------
			Mike Davis ..!att!ihlpm!jmdavis

char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

raz@kilowatt.uucp (Raz- Berry) (04/28/89)

In article <11430@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)In article <33747@kilowatt.uucp> raz@kilowatt.uucp (Raz- Berry) writes:
)) I need a basic flowchart
)) on taking a 4096 color palette and converting it down to
)) 256. Initially I was thinking that:

)) [I take a first stab at a HAM conversion routine ... deleted]

)	Permit me to poke a hole in this.

) [Leo, armed with a short sword, makes swiss cheese out of my first pass]

)...  However, that white line is a
)prominent feature, because of its contrast with the rest of the image.  So
)picking colors for a reduced bitmap isn't all that simple.

Yeah, I had similar thoughts. I recognized the problem, I was hoping some
one could 'show me the way' to enlightened color mapping techniques. As
it turns out, a fellow named Tony Kennedy sent me some very interesting
conversion and dithering routines. Perhaps the version after the next release
will include dithering routines as well as HAM capability. So if I include
HAM conversion, you can all thank Tony.

BTW: I have included Extra-Half-Bright support to iff2sun and I will be
posting to Bob the new source soon. I am not too happy with the way
320x400 images look on a Sun color monitor though. There is a definate
elongation effect because of the different aspect ratio between the two
machines. So far the best results have been with 640 (or larger) x400
images 'rastrepl'ed once, to fit the Sun screen. I like the hires LION
that comes with PixMate... looks pretty good on mono.

)	I had to attack similar problems when writing some internal tools
)when we were developing Roger Rabbit.  I strongly recommend you get yourself
)a book on image processing (something I should have done).

Gee, I suppose sharing the RR code is out of the question huh? ;-)

)_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
)Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU

-- 
Steve -Raz- Berry      Disclaimer: I didn't do nutin!
UUCP: sun!kilowatt!raz                    ARPA: raz%kilowatt.EBay@sun.com
"Fate, it protects little children, old women, and ships named Enterprize"

coy@ssc-vax.UUCP (Stephen B Coy) (04/28/89)

In article <11430@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
> In article <33747@kilowatt.uucp> raz@kilowatt.uucp (Raz- Berry) writes:
> > I need a basic flowchart
> > on taking a 4096 color palette and converting it down to
> > 256. Initially I was thinking that:
> >
> > [algorithm deleted for brevity]
> 
> 	Suppose I have a simple HAM picture.  The left half of the screen is
> various hues of purple, and the right half of the screen is various hues of
> blue.  Separating these two fields is a vertical line, one pixel wide, that
> is solid white.
> 
> 	Now, if you were to do a histogram on this image, you'd probably
> find the most popular 256 entries were hues of purple and blue, and white
> would be right at the bottom of the list.  However, that white line is a
> prominent feature, because of its contrast with the rest of the image.  So

But rememeber, he's starting with a 4096 color palette which means
only 16 hues of pure blue.  Even allowing for going slightly off
color you'll probably end up with less than 50 shades each of blue
and purple.  This still leaves over 100 palette entries for various
shades of white.  When DBW_render first appeared I coded up the
algrothm as proposed for displaying the images on an Apollo with a
256/16M palette.  The images looked fine.  For mapping the
non-popular colors onto the 256 color palette I used a simple
distance function in RGB space.  Obviously not the best but good
enough.

Stephen Coy
uw-beaver!ssc-vax!coy

raz@kilowatt.uucp (Raz- Berry) (04/29/89)

In article <3404@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes:
>First, you may want to post this to comp.graphics also. There

Yeah, I should have. I figured that there are a *LOT* of Amiga people
who know of (or at least where to look for) methods to do this.

>Second, I wouldn't weigh BLUE as heavily as I would RED and
>GREEN. BLUE is harder for humans to see. This would have drastic

Good to know.

>Third, I don't think .tech is the appro place for this (but I am
>not sure, so I post here too). .tech is for technical Amiga stuff,
>you have asked a technical graphics question, not dealing with amiga
>system function calls, amiga system programming, etc.

Hmm, that sounds like comp.sys.amiga.tech.programming to me.

This was a technical question on converting the Amiga palette down to
one that can be used on a Sun. Iff2sun is a utility used by people who
have Amiga's and want to display pictures they have on Sun machines.

Lets' see, technical Amiga question about a utility used ONLY by people
who have Amiga's. Maybe I should post to alt.sex. ;-)

>			Mike Davis ..!att!ihlpm!jmdavis



-- 
Steve -Raz- Berry      Disclaimer: I didn't do nutin!
UUCP: sun!kilowatt!raz                    ARPA: raz%kilowatt.EBay@sun.com
"Fate, it protects little children, old women, and ships named Enterprize"

doug@xdos.UUCP (Doug Merritt) (05/01/89)

In article <3404@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes:
>Second, I wouldn't weigh BLUE as heavily as I would RED and
>GREEN. BLUE is harder for humans to see.

This amounts to gamma correction, doesn't it?
	Doug
-- 
Doug Merritt			Member, Crusaders for a Better Tomorrow
{pyramid,apple}!xdos!doug	Professional Wildeyed Visionary

"Of course, I'm no rocket scientist" -- Randell Jesup, Capt. Boinger Corps

bdb@becker.UUCP (Bruce Becker) (05/07/89)

In article <254@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
|In article <3404@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes:
|>Second, I wouldn't weigh BLUE as heavily as I would RED and
|>GREEN. BLUE is harder for humans to see.
|
|This amounts to gamma correction, doesn't it?

	Nope.

-- 
   __	 Bruce Becker	Toronto, Ont.
w \cc/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/v/-e	 BitNet:   BECKER@HUMBER.BITNET
_<  >_	 "Where is Newton Minow now that we need him?" - T. S. Eliot

douglee@becker.UUCP (Doug Lee) (05/07/89)

In article <482@becker.UUCP> bdb@becker.UUCP (Bruce Becker) writes:
>In article <254@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>|In article <3404@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes:
>|>Second, I wouldn't weigh BLUE as heavily as I would RED and
>|>GREEN. BLUE is harder for humans to see.
>|
>|This amounts to gamma correction, doesn't it?
>
>	Nope.

I can't stand just a simple Nope without an explaination:-). Gamma correction
is nonlinear amplification applied to the video signal's amplitude to compensate
for the fact that television picture tubes are nonlinear EG: twice as much 
video level doesn't make the picture twice as bright. Correction for this is
always applied in TV cameras (Commercial ones, I don't know about the cheap
home ones). The ratio between R G and B signals when mixed to produce monochrome
is something else entirely. The ratio is something like 11% Blue, 59% Green and 
the rest Red. These are not necessarily the CORRECT figures as I don't have
them right here. If anyone really needs to know, I can look it up later.
			    <<<Doug>>>

>
>-- 
>   __	 Bruce Becker	Toronto, Ont.
>w \cc/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
> `/v/-e	 BitNet:   BECKER@HUMBER.BITNET
>_<  >_	 "Where is Newton Minow now that we need him?" - T. S. Eliot