rademach@boulder.Colorado.EDU (Simon Rademacher) (02/18/90)
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 =
harlick@plains.UUCP (Ryan) (02/18/90)
I have a program that converts GIF files to sliced ham format. It practically eliminates the fuzziness of normal ham. If you want in send me a message. It really does a good job. Yours truly, Ryan Harlicker harlick@plains.nodak.edu
scotth@corp.sgi.com (Scott Henry) (02/19/90)
A while ago I was trying to convert 24bit RGB images to HAM (I never finished the project, I didn't have a good IFF-writing function). The key to making a good HAM image is that HAM images perform poorly on color changes. Therefore, what you want to do is make the color registers contain pixels with the biggest color shifts. The algorithm I came up with requires two passes on the image. I defined the "distance" between 2 adjacent pixels as: 0 if the second pixel differed in only one of RGB from the previous one, or the sum of the square of the difference of the smaller two different colors. Basically, I was trying to attach a number to the HAM error. First pass: I arbitrarily defined border (for the first pixel on each line) as black (r=0,g=0,b=0). I then computed the distance between all adjacent pixels, and stored them in an array, along with the RGB values of the pixel. I sorted the array to put the highest errors first. If there were more than 15 colors with error > 0 (remember that color 0 is taken as 0,0,0), then I was going to try several optimizations of the colors selected for the registers. The first one (the only one I tried) was to map out any colors that happened to be within +- 1 in any single R, G, or B from another register. Other optimizations required keeping a count of the pixels affected by the error, so as to minimize the number of error pixels. Second pass: scan through the image. If a pixel was equal to a color register, use it, else compute the HAM error -- if it was less than the best register, compute the HAM delta, else use the closest register. Hope this helps people make better HAM conversion programs -- most of the ones I've seen do a lousy job (one reason I started writing my own -- one of these days I'll go back and finish it). -- Scott Henry <scotth@sgi.com> | These are my | Tardis Express -- when it Information Services, | Opinions only!| absolutely, positively Silicon Graphics, Inc | Whose else? | has to be there -- yesterday.
dfrancis@dsoft.UUCP (Dennis Heffernan) (02/20/90)
[yum!] RE Converting MacII graphics to Amy SOMEwhere out there, supposedly, is a program that converts GIF files to Digi-View files (called IP files, I belive.) I can't seem to find it. If such a beast exists, it would solve your problems. Assu ming you have Digi-View, of course. I've got (from BIX) a program that takes advantage of Digi-PAINT's ability to read a scan line at a time from its rexx port to feed TMP format pics (from GIFTOTMP, part of a GIF to IFF converter and GIF to SHAM) into Digi- Paint. DP does a nice rendering job, BUT the utility makes no attempt at chosing a palette. You have to fiddle with the 16-color palette yourself until you get results you like. The only real advantage to this is that you can take big GIFs and turn them into HAM super bitmaps, if you have the RAM, and turn THEM into Dynamic HiRes shots with Digi-View 4.0. If anyone out there has seen the GIF to IP (or whatever Digi-View likes to call its raw RGB format), lemme know where you saw it. (I don't even know what FTP is, let alone have access to it, so I'd appreciate BBS's or pay services.) -- --dfh ...uunet!tronsbox!dsoft!dfrancis "Great spirits have always encountered violent opposition from mediocre minds." -Albert Einstein