yk4@cunixb.cc.columbia.edu (Yong Su Kim) (11/26/90)
I was playing around with Jonah Stich's 3200 gif converter, and it struck me that there had to be a better way of converting gifs into 3200 colour pictures on the GS. Jonah's program is extremely slow in converting gifs into 3200 colour modes using the Median Cut algorithim. I don't really see why he uses the median cut algorithim since median cut algorithim involves areas. All he really has to do is use the popularity algorithim on each individual scan line. That way it's possible to cut down on a lot of processing time. Another solution might be to write a 3200 gif converter for the GS using C so that it runs under standard UNIX. The programmer could design it such that it accepts standard UNIX binary files as gifs, process them using various optimization algorithims for 3200 colour mode, and then output a binary file which can then be downloaded to my GS. All I would have to do is change the filetype and then I would be able to view the conversion. This would be much much quicker and it would probably allow for superior conversions. Anyone out there have the time to write such a program? I would do it if I had the time and the knowledge... _____________________________________________________________________________ |Internet: yk4@cunixb.cc.columbia.edu |||||||||||Yong Su Kim|||||||||||| |Bitnet : yk4@cunixc |||||The Korean from Hong Kong|||| |UUCP : uunet!rutgers!columbia!cunixc!yk4 |||||||...Apple IIGS user...|||||| |____________________________________________||||||||||||||||||||||||||||||||||
russotto@eng.umd.edu (Matthew T. Russotto) (11/27/90)
In article <1990Nov26.055040.14047@cunixf.cc.columbia.edu> yk4@cunixb.cc.columbia.edu (Yong Su Kim) writes: >I was playing around with Jonah Stich's 3200 gif converter, and it >struck me that there had to be a better way of converting gifs into >3200 colour pictures on the GS. > >Jonah's program is extremely slow in converting gifs into 3200 colour >modes using the Median Cut algorithim. I don't really see why he uses >the median cut algorithim since median cut algorithim involves areas. >All he really has to do is use the popularity algorithim on each >individual scan line. That way it's possible to cut down on a lot of >processing time. In fact, neither algorithm is very satisfactory-- the problem is that you need consistency from one scan line to the next, and neither algorithm will give that to you consistently-- popularity seems to do a bit better than median cut, but some 16-color median cuts look as good as 3200 color popularity pictures. (I have some REAL UGLY 3200s to prove it) I don't think median cut is inherently slower than popularity, BTW. >Another solution might be to write a 3200 gif converter for the GS >using C so that it runs under standard UNIX. The programmer could >design it such that it accepts standard UNIX binary files as gifs, >process them using various optimization algorithims for 3200 colour >mode, and then output a binary file which can then be downloaded to my >GS. All I would have to do is change the filetype and then I would be >able to view the conversion. This would be much much quicker and it >would probably allow for superior conversions. > >Anyone out there have the time to write such a program? > >I would do it if I had the time and the knowledge... Forget writing one from scratch-- take a look at the pbmplus programs-- there seems to be one for everything, and one ought to be easily modified to do what you want. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (11/27/90)
In article <1990Nov26.055040.14047@cunixf.cc.columbia.edu> yk4@cunixb.cc.columbia.edu (Yong Su Kim) writes: >Another solution might be to write a 3200 gif converter for the GS >using C so that it runs under standard UNIX. The programmer could >design it such that it accepts standard UNIX binary files as gifs, >process them using various optimization algorithims for 3200 colour >mode, and then output a binary file which can then be downloaded to my >GS. All I would have to do is change the filetype and then I would be >able to view the conversion. This would be much much quicker and it >would probably allow for superior conversions. Better yet, write a C program that takes a GIF file and turns it into raw picture data--two 16-bit words for picture size, followed by a stream of 24-bit pixel data. Yes, this would create huge files on your UNIX box, but you then write a separate program to take the 24-bit color data and munge it for whatever graphic mode you want--Hi-Res, double Hi-Res, 320-mode super Hi-Res, 3200-color, or you could even use the 24-bit decoder in conjunction with a converter for almost any graphic mode on any computer. (You won't see it, but damn this line noise I'm getting! :-( ) ----------------------------------------------------------------------------- Scott Alfter _/_ / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/
scottg@gnh-starport.cts.com (Scott Gentry) (12/01/90)
In a previous post, Yong Su Kim said something like... "I was playing around with Jonah Stich's 3200 gif converter, and it struck me that there had to be a better way of converting gifs into 3200 colour pictures on the GS. Jonah's program is extremely slow in converting gifs into 3200 colour modes using the Median Cut algorithim. I don't really see why he uses the median cut algorithim since median cut algorithim involves areas. " Maybe, but you try it sometime. It ain't the easiest thing in the world to do. Jonah's median cut does work on each scan line as it processes therefore, the only area the algorithm works with is a 1 x Width area. Now, then I know for a fact that the next version on GIF 3200 (probably not called GIF 3200) will be lots faster, but it's still using the median cut. It's pretty accurate, too. Tell ya what, for what it does, NOW, GIF 3200 honks. I think perhaps you should adjust your expectations. There is NO easy way to make 3200 color pictures. _______________________________________________________________________________ | Scott Gentry * ALPE AFL Scott * I never said that!| | 2051 Mercator Drive * GEnie W.GENTRY * But you never | | Reston, VA 22091 * UUCP: uunet!ingr!ne1300! * know! | | (703) 264-5652 * brnded!scott * Do You? | |_____________________________________________________________________________|
scottg@gnh-starport.cts.com (Scott Gentry) (12/01/90)
In a previous message, Scott Alfter said something like ... "Better yet, write a C program that takes a GIF file and turns it into raw picture data--two 16-bit words for picture size, followed by a stream of 24-bit pixel data. Yes, this would create huge files on your UNIX box, but you then write a separate program to take the 24-bit color data and munge it for whatever graphic mode you want--Hi-Res, double Hi-Res, 320-mode super Hi-Res, 3200-color, or you could even use the 24-bit decoder in conjunction with a converter for almost any graphic mode on any computer. (You won't see it, but damn this line noise I'm getting! :-( ) " Welp, you should really try what you're suggesting sometime. At 24 bits per pixel (8 bits per component), a 320x200 file takes 192,000 bytes. Turns out you don't gain much in terms of quality when you _try_ to expand an image whose components are 4 bit, because the image has already had it's color map reduced. There is virtually no way to synthesize more color in an image than is already present, except in the case of contrast/brightness enhancement. With that in mind, here's how you turn a 4 bit image into a "24 bit raw" as you put it image... multiply each component by 17. Keep in mind, though, unless you've got raw data to start with, you'll never get more than 16 colors from a colormap of a GIF image that originated on the GS. _______________________________________________________________________________ | Scott Gentry * ALPE AFL Scott * I never said that!| | 2051 Mercator Drive * GEnie W.GENTRY * But you never | | Reston, VA 22091 * UUCP: uunet!ingr!ne1300! * know! | | (703) 264-5652 * brnded!scott * Do You? | |_____________________________________________________________________________|