Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!rademach From: rademach@boulder.Colorado.EDU (Simon Rademacher) Newsgroups: comp.sys.amiga Subject: HAM registers (long), was: Re: MacII Graphics to Amiga Summary: ham color register selection Message-ID: <17098@boulder.Colorado.EDU> Date: 17 Feb 90 21:38:17 GMT References: <2934@bingvaxu.cc.binghamton.edu> <26885@cup.portal.com> Sender: news@boulder.Colorado.EDU Reply-To: rademach@boulder.Colorado.EDU (Simon Rademacher) Organization: University of Colorado, boulder Lines: 78 In article <26885@cup.portal.com> Koa@cup.portal.com (Ken Alan Feliciano) writes: >A program called HAMSHARP takes longer to convert 256 color images, but it >seems to do a better job (i.e. much less HAM fringy-things) than VIRTGIF. >----- Ok, so where can I get a copy of Hamsharp? It might be was I'm looking for since: I've been trying to convert some 256 color gif images to HAM. I haven't been able to get very good quality mostly due to the HAM "fringy-things." I'm looking for a program to run under unix rather than on the Amiga. (This should make it easier to find programs, I hope.) Anyway, I'm currently using a hacked up PBMplus conversion program. The original loaded the color registers with the 16 gray shades and this did not produce the best of results. So I tried to write a new algorithm for choosing the color registers. Well, right now, I just choose the 16 most popular colors of the picture. However, this has drawbacks, too. Since a picture may often contain a large number of similar shades, this may produce two or more color registers with almost exactly the same color and leave out colors that are not common, but quite different from most of the other colors in the picture. I've been thinking about an algorithm that would choose colors whose weights are bassed both on frequency and distance (in rgb space) from any/all previous colors choices for registers: something like frequency + sum of distances to all previously chosen colors, with appropriate scaling factors. This should (?) allow colors that stand out, but are not too common to be chosen, as well as choosing a lot of common colors. One important factor that is not really taken into account here is that color "distances" are not really linear in HAM. For instance, consider a 3-d color space with axies r,g,&b. The euclidian distance from black to a medium red (000-900) would be 9 units. Now consider a point that is also 9 units away from black but positioned on the line from black to white (fff) (ie, equidistant from each axis, or grey). Now, if a point on a HAM screen is black and the next is red, we can display the red exactly with a HAM operation. (It lies on a line parallel with an axis and passes through the previous pixel's color.) However, we cannot display the given grey, or even one with a euclidian distance of 2 (rounded from sqrt(3)) exactly with a HAM operation. Similarily, pixels which lie on planes parallel with planes formed by two axies have advantages over those that don't, but not as great as those on parallel lines. How, then, can this be taken into account when choosing color registers? Or is it even worth considering at this point? Perhaps it only plays a significant role in deciding how to color a given pixel given the previous pixel and the next pixel. What I'm striving for in color register choices is to put colors that stand out into registers even though they do not have a very high frequency. Since colors that stand out generally attract attention, it is important to avoid fringes here. However, I don't want to completely sacrifice the quality of the large areas, either. An example may help: a picture is mostly bright blues with a smaller red spot. That red would be chosen for a color register since its distance to the blues is far. This is important since HAM would not be able to get from a blue (previous pixel) to the dark red in one pixel or even two. (Greys are better in this case, since it could get there in two pixels, but having red in a register is even better.) However, we also want a lot of blues to handle areas that change too fast for HAM to handle. So, does the above sound like a reasonable approach? Anybody got any hints? Maybe somebody already has a good algorithm to select the colors for the registers and would like to share it. Or maybe there's already a program which does the whole conversion nicely that someone can point me to (like Hamsharp mentioned at the start. Of course, if it only reads Mac files, I'd need yet another program to convert from gif to mac.) Is there a newer version of the FuzzyBitMap program that handles HAM? Better yet, is there a program to convert to the "special" graphics modes (called things like S-HAM or dyna-HAM or whatever) and a viewer program? I know I can get better results than I have so far. Thanks much for any light shed. ======================================= = Simon Rademacher = = rademach%tramp@boulder.colorado.edu =