arc@desire.wright.edu (06/28/90)
In article <caw.1727@miroc.Chi.IL.US>, caw@miroc.Chi.IL.US (Christopher A. Wichura) writes: > I have been working on a program that converts GIFs into IFFs. It is done > except for the fact that it does a lousy job of selecting the base colours > used in HAM mode. Currently, I simply make a list of all the colours > actually used and then take the first 15 (colour 0 is the background) and > use them for the base colours. I did this because I was at a loss for an > intelligent way to decide on the base colours and wanted to get on with the > rest of the program, such as the IFF writer, etc. Now everything else has > been done and I still am at a loss for a good algorythm. > > Anyone out there wanna offer some suggestions? I thought about a > clustering routine, but the guy I know who has dealt with clustering said > most cluster algorythms have quirks that would make them unsuitable for > what I want to do. > > The way I have written the coverted, I am not limited to selecting fifteen > of the total colours used. If some other colour would work better then it > can be used. > > As it stands, just using the first 15 gives decent results, but one still > gets very noticable areas, particurarily along edges between to very > different areas (such as the edges of a black chair on a white background). > Now I know one can't get a perfect picture, but HamSharp does a better job > on such edges than my program and, aside from speed, thats about the only > thing HamSharp has going for it :-). > > Just to let `water your mouth' :-), GIFMachine allows one to specify > whether you want the image width halved (HamSharp always does this) and if > yes then it actually thinks about it a bit rather than simply dropping the > odd pixel columns like HamSharp does. It can also automatically remove > border regions from a picture (I just hate it when you have a little > picture in the center with inches of nothing around it!). It's more robust > at writing IFFs as well (HamSharp writes corrupt IFFs for me on a regular > basis). I also use the arp.library GADS() call (among other things) and it > handles wildcards and the TO keyword in a manner much like the ARP C:MOVE > command. GIFMachine is also fully residentiable and is about 5k smaller > than HamSharp as well. > > Of course, the best thing for converting GIFs is ASDG's The Art Department, > but you gotta have LOTS of memory for that (not that GIFMachine doesn't > soak up memory, but at least it doesn't have to be continguous (sp?) like > when using TAD). > > -=> CAW > > /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > Christopher A. Wichura > > caw@miroc.chi.il.us (my amiga) > u12401@uicvm.uic.edu (my school account) > > Please! Do not send mail to my school account unless mail to miroc bounces. > I often do not check uicvm.uic.edu for periods in excess of a week. > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////// Chris, I am no math man, BUT, I've worked with HAM some, and I find that if your base palette contains black (not including the color 0(background)) or dark colors (dark dark!) that you SHOULD look in the GIF file for some primary colors, and maybe put them in the palette, also take some of the colors and put them in the dark ones that was found in the first 16 colors of the GIF... I hope this message wasn't too confusion, since it is very early and I feel so sleepy...
dn0o+@andrew.cmu.edu (Derek Brooks Noonburg) (06/29/90)
I believe something like this went by on comp.sys.graphics about a year ago.
They suggested the median cut algorithm devised by Paul Heckbert (I think).
It was published in a SIGGRAPH Proceedings a couple years ago -- send me
email and I'll look up the exact issue (it's at home).
The basic idea is to create a histogram of RGB space (i.e., 16x16x16 array
where each element is the number of pixels of that color). Then choose
the direction (R/G/B) with the widest span. Split the histogram at the median
color along that direction. Repeat this recursively (using the regions created
by your previous splits instead of the whole histogram) until you have 16 (or
however many) colors.
I use this method for my own GIF viewer and it works quite well. Actually,
the 32-color lo-res images look almost as good as HAM. I can send the code, if
you want.
BTW, If you have a good way of generating HAM colors (the actual pixel values)
once you have the base colors, I'd be interested in hearing about it.
- Derek
==========================================================================
Derek Noonburg | ARPA: dn0o+@andrew.cmu.edu
Junior - Computer Engineering | BITNET: dn0o+@andrew / dn0o+%andrew@cmccvb
Carnegie Mellon University | UUCP: ...harvard!andrew.cmu.edu!dn0o+
USMail: Box 967; 5115 Margaret Morrison St.; Pittsburgh, PA 15213
==========================================================================podlipec@dg.dg.com (Mark Podlipec) (07/01/90)
Derek descibed Paul's algorithm in a previous post so I won't repeat, but
I've found it works fairly well.
I've played around with where you make the 'cut' when dividing the
boxes. Instead of splitting based on the median color, take into
account the number of pixels and split at the median pixel. I've found
this on average to produce better HAM images(closer to the original GIF).
On the side, I've been playing with creating Dynamic Hi-Res and for the
most part they look good, except on some images my current algorithm
generates some horizontal banding due to treating each line separately.
Has anyone written code to take adjacent lines into account during color
selection and would like to offer suggestions?
Mark Podlipec
"Can't you see the falling petals?" - Naja
"uh?" - Dave Betsonski