Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!uoft02.utoledo.edu!desire!arc From: arc@desire.wright.edu Newsgroups: comp.sys.amiga.tech Subject: Re: Selecting HAM mode base colours Message-ID: <673.2689a856@desire.wright.edu> Date: 28 Jun 90 11:48:54 GMT References: Lines: 64 In article , 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...