cs442a07@cs.iastate.edu (Sunny the Great) (04/19/91)
Hi, I couldnt find any info about this from other sources, so I decided to ask. I would like to find a utility (PC-based or C-source) which takes a gif file, and converts it in the following fashion: The color numbers are re-ordered so that near-to-each-other pixels are near to each other in color number; and The picture is re-compressed using thefollowing ordering of pixels: ---------> ^------->| |^----->|| |<------v| <--------v (Hopefully making the compression more efficient... If such an option exists in PBMPLUS, then which option is it, and where can I find a pre-compiled for IBM PC version of PBMPLUS? Thank you for your time. -- Sunjeev "Sunny" Gulati, student, Iowa State University cs442a07@zippy.cs.iastate.edu taa65@ccvax.iastate.edu (515)-296-9537 "I have nothing better to do than procrastinate" - Myself
cs442a07@cs.iastate.edu (Sunny the Great) (04/19/91)
cs442a07@cs.iastate.edu (Sunny the Great) writes: I thought I had better clarify what I meant.... >I would like to find a utility (PC-based or C-source) which takes a gif >file, and converts it in the following fashion: ------------- Actually it can be any kind of picture >The color numbers are re-ordered so that near-to-each-other pixels are >near to each other in color number; More on this below >and The picture is re-compressed using thefollowing ordering of pixels: >---------> >^------->| >|^----->|| >|<------v| ><--------v >(Hopefully making the compression more efficient... >If such an option exists in PBMPLUS, then which option is it, and where can >I find a pre-compiled for IBM PC version of PBMPLUS? ----- begin clarification Its simple really - I want the picture to be a little more compressible than it normally is... I should have mentioned that it could be any picture, not a gif file. If you take the pixels in the order given previously, then there is no "jump" as we go from one scan line to another... this smooth transition (to my mind) means a better chance to compress this picture. As for re-ordering the color numbers, if we have a stream of colors which looks like this: 05243671 and the colors (on the screen) are a red to Yellow progression, then we define new color 1=old color 5, new 2= old 2, new 3=old 4 etc so that we get 01234567 (which still looks the same) makes it more compressible, if only the differences between p(x) and p(x+1) are stored. (I think. I am by no means even an amateur). Basically, re-order the elements so that the average difference between x and x+1 is minimized. Reason why: I intend to have lots of picfiles. While GIFs do a good job compressing the pictures, if the pictures are decompressed, translated as above and then recompressed (with PKZIP or ARJ or LHARC or whatever) I might be able to save space... even 5% is welcomed. -- Sunjeev "Sunny" Gulati, student, Iowa State University cs442a07@zippy.cs.iastate.edu taa65@ccvax.iastate.edu (515)-296-9537 "I have nothing better to do than procrastinate" - Myself
paulf@shasta.Stanford.EDU (paulf) (04/20/91)
In article <cs442a07.672031798@zaphod> cs442a07@zippy.cs.iastate.edu writes: >The color numbers are re-ordered so that near-to-each-other pixels are >near to each other in color number; We considered doing such a thing a while back. The scheme I proposed was to take the color map, convert to YIQ, sort the colors according to I, greycode the list (so colors close in intensity are close bitwise), and convert the image. While this would do wonders for true Lempel - Ziv, it won't do anything for Lempel - Ziv - Welch, which is a BYTE oriented compression scheme. So, as my Math Phil prof once put it, "the ship sinks". -=Paul Flaherty, N9FZX | "Think of it as evolution in action." ->paulf@shasta.Stanford.EDU | -- Larry Niven and Jerry Pournelle
rdippold@cancun.qualcomm.com (Ron Dippold) (05/03/91)
In article <cs442a07.672064530@zaphod> cs442a07@zippy.cs.iastate.edu writes: >cs442a07@cs.iastate.edu (Sunny the Great) writes: > >I thought I had better clarify what I meant.... > >>I would like to find a utility (PC-based or C-source) which takes a gif >>file, and converts it in the following fashion: >[...] >Its simple really - I want the picture to be a little more compressible >than it normally is... > >Reason why: I intend to have lots of picfiles. While GIFs do a good job >compressing the pictures, if the pictures are decompressed, translated as above >and then recompressed (with PKZIP or ARJ or LHARC or whatever) I might >be able to save space... even 5% is welcomed. Have you considered using a JPEG compressor? That usually compresses GIFs down to about %50-%70 percent of their original size for me. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
technews@iitmax.iit.edu (Kevin Kadow) (05/04/91)
I have noticed that different programs write GIF files in slightly different
manners (algorithms etc).
If you take a well written converter (say JPEG at 100% or GWS for IBM/PC) and
covert:
GIF -=> PCX (or any other no-quality-loss format)
then
PCX -=> GIF (effectivly ending up where you started)
the result is an identical PICTURE, but not an identical file- it may be shorter
(or longer) or display faster/slower depending how good the program is.
I've got a PD JPEG for IBM- is it available for AMIGA?
If anybody REALLY needs Jpeg, I *could* e-mail a copy (trade?) of mine.
--
technews@iitmax.iit.edu kadokev@iitvax (bitnet)
My Employer Disagrees.