leo@s514.ipmce.su (Leonid A. Broukhis) (06/04/91)
Hello !
I have some problems when converting GIF files to JPEG format
(using Image Alchemy 1.4 under MS-DOS).
There are some GIF images (320x200,256) which have inacceptable
distortions (green dots on human face, lack of luminance, etc)
after conversion to JPEG (even with quality > 100!!),
and these distortions are independent of the quality.
Is this due to incorrectness of the JPEG implementation
or due to JPEG algorithm?
Thanks...
--
Leonid A. Broukhis | 89-1-95 Liberty St. | "BROUKHIS" is Hebrew for
7+095 494.6241 (h) | Moscow 123481 USSR | "BENEDICTAE"
7+095 132.9475 (o) | (leo@s514.ipmce.su) | {Licet omnia qualibet dicas}d88-jwa@byse.nada.kth.se (Jon W{tte) (06/04/91)
.ipmce.su (Leonid A. Broukhis) writes:
I have some problems when converting GIF files to JPEG format
(using Image Alchemy 1.4 under MS-DOS).
Why can't people get it; conversion of GIF to JPEG is a really
stupid thing to do. JPEG works better (gives smaller output with
better output) if applied to the original 24bit RGB source than
if applied to the already-quantified 8-bit GIF images. This is
because of "unnatural" noise and high frequency generated by the
quantification process.
--
Jon W{tte
h+@nada.kth.se
- Speed !gwing@mullauna.cs.mu.OZ.AU (Geoff C Wing) (06/04/91)
leo@s514.ipmce.su (Leonid A. Broukhis) writes: >There are some GIF images (320x200,256) which have inacceptable >distortions (green dots on human face, lack of luminance, etc) >after conversion to JPEG (even with quality > 100!!), >and these distortions are independent of the quality. > Is this due to incorrectness of the JPEG implementation >or due to JPEG algorithm? It's due to the algorithm. JPEG achieves such excellent compression ratios for picture and sound data at the expense of exact representation. It's a quality sacrifice to gain quantity. | Geoff C Wing | \ _ _ _ _ __ |gwing@mullauna.cs.mu.oz.au | // \ |\/| | / __ /\ |gwing@munmurra.cs.mu.oz.au | \X/ /\ \ | | _|_ \__| //\\ |static@phoenix.pub.uu.oz.au|
rdippold@cancun.qualcomm.com (Ron Dippold) (06/05/91)
In article <D88-JWA.91Jun4173548@byse.nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >.ipmce.su (Leonid A. Broukhis) writes: > > I have some problems when converting GIF files to JPEG format > (using Image Alchemy 1.4 under MS-DOS). > >Why can't people get it; conversion of GIF to JPEG is a really >stupid thing to do. JPEG works better (gives smaller output with >better output) if applied to the original 24bit RGB source than >if applied to the already-quantified 8-bit GIF images. This is >because of "unnatural" noise and high frequency generated by the >quantification process. Well, get this. GIF to JPEG works great for me on digitized GIF files of resolution 640x400x8 or better (which are the majority). With no visible loss of fidelity it compresses down to 10% to 25% of the original GIF file. It's nowhere near the savings realized on a 24-bit file, but is nothing to complain about. People get excited over 8% better compression of programs and text - being able to fit 4 to 10 times the number of GIF files on a single floppy disk in no way strikes me as a "really stupid thing to do," any more than compression of anything else. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
minakami@neon.Stanford.EDU (Michael K. Minakami) (06/05/91)
In article <D88-JWA.91Jun4173548@byse.nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >.ipmce.su (Leonid A. Broukhis) writes: > > I have some problems when converting GIF files to JPEG format > (using Image Alchemy 1.4 under MS-DOS). > >Why can't people get it; conversion of GIF to JPEG is a really >stupid thing to do. JPEG works better (gives smaller output with >better output) if applied to the original 24bit RGB source than >if applied to the already-quantified 8-bit GIF images. This is >because of "unnatural" noise and high frequency generated by the >quantification process. Perhaps it has never occurred to anyone that people do not have the original >8-bit images. There is also no guarantee that the original would be >8 bit. Leonid's criticism would perhaps be better if he applied it to dithered gif images; these do generally contain high-frequncy data that would not be preserved in JPEG conversion. However my experience has been that at high quality levels, even dithered images maintain are not distorted much. Second, Image Alchemy, at least in the early versions, had a problem with conversion with high qualities. The resulting image would appear blocky; definitely not of high quality. I'm not sure if this has been fixed in subsequent releases. A final qustion: Has anyone tried going from 8-bit gif -> jpeg -> 24-bit gif? Specifically, is the 24-bit gif of higher quality than the 8-bit gif given that jpeg "extrapolates" a 24-bit representation from the 8-bit representation? --Mike -- ------------------------------------------------------------------------------- Michael Minakami | These thoughts are my own, not that anyone's Computer Science/Psychology | tried claiming them. Stanford University |
d88-jwa@byse.nada.kth.se (Jon W{tte) (06/05/91)
@cancun.qualcomm.com (Ron Dippold) writes: >stupid thing to do. JPEG works better (gives smaller output with >better output) if applied to the original 24bit RGB source than >if applied to the already-quantified 8-bit GIF images. This is Well, get this. GIF to JPEG works great for me on digitized GIF files of resolution 640x400x8 or better (which are the majority). With no visible loss of fidelity it compresses down to 10% to 25% of the original GIF Hmm, well, to each his own. I didn't know GIF supported better than the x8 - it doesn't in the spec sheet _I_ look at. Look at it this way: the GIF you have must come from somewhere. From what I know, there are no GIF-generating scanners, no, they generate 24bit images which have to be quantified and color-index-coded into gif images. Why not go after the sources ? In a few years, of course, this discussion will be academic, but I suggest people really try to get the originals for JPEG encoding, since the gain is so obvious. -- Jon W{tte h+@nada.kth.se - Speed !
rdippold@cancun.qualcomm.com (Ron Dippold) (06/06/91)
In article <D88-JWA.91Jun5105246@byse.nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >Look at it this way: the GIF you have must come from somewhere. From >what I know, there are no GIF-generating scanners, no, they generate >24bit images which have to be quantified and color-index-coded into >gif images. Why not go after the sources ? Because currently there are so many more GIFs available than there are 24-bit files, including ones that I need that I can never get the originals to, most likely. When I can, I JPEG from the 24-bit files. When I can't, well it will work on the GIFs. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/10/91)
In article <1991Jun4.223719.2958@qualcomm.com> rdippold@cancun.qualcomm.com (Ron Dippold) writes: | Well, get this. GIF to JPEG works great for me on digitized GIF files of | resolution 640x400x8 or better (which are the majority). With no visible loss | of fidelity it compresses down to 10% to 25% of the original GIF file. It's This is a source of great discussion. Some people feel that there is not visible data loss, others think that it is unacceptable. The argument advanced is that the image is not perfect anyway, so why would a little more degradation matter? I think that everyone would agree that a lossless compression with the same results would be better, the question is one of reduced quality vs running out of space. I personally use JPEG for some images, and keep the rest offline. I have a pair of 320MB drives to ease the choices. I have a friend who has 1.5GB of images and keeps them on 150MB tape because he can't stand JPEG. I don't think JPEG is acceptable to everyone, I do think it's a valuable tool for those who either can't see the difference, can accept the changes, or who have images which respond well to JPEG compression. Trying to convince someone that JPEG is (or isn't) suitable is a waste of time, since there is no objective answer. Hopefully fractal compression will get here soon. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/10/91)
In article <D88-JWA.91Jun5105246@byse.nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: | In a few years, of course, this discussion will be academic, but I | suggest people really try to get the originals for JPEG encoding, | since the gain is so obvious. I agree. JPEG works much better when compressing a 24 bit Targe file, which can then be turned into a GIF for viewing. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
madler@nntp-server.caltech.edu (Mark Adler) (06/11/91)
The talk about JPEG being acceptable or not seems to imply that there is a such a thing as "the" JPEG. There isn't. You can set the compression level (roughly) by varying the quantization parameters from no quantization (lossless decompression, up to round-off errors in the DCT), to a great deal of quantization, the latter resulting it really awful looking, blocky decompression (at about the 30:1 to 50:1 level). Setting these parameters is still rather a black art, but up to a point, you have control over the resulting quality of the decompressed images. Mark Adler madler@tybalt.caltech.edu
mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) (06/11/91)
madler@nntp-server.caltech.edu (Mark Adler) writes: >[in JPEG] You can set >the compression level (roughly) by varying the quantization parameters >from no quantization (lossless decompression, up to round-off errors >in the DCT), to a great deal of quantization, the latter resulting >it really awful looking, blocky decompression (at about the 30:1 to >50:1 level). In addition, the JPEG standard describes an absolutly lossless method that doesn't use DCT. Each pixel is predicted by the values of three of its neighbours. But this results only in a 1:2 (?) compression for moderatly complex images. Markus --- Markus Kuhn, Computer Science student -- University of Erlangen, Germany X.400: G=Markus;S=Kuhn;OU1=rrze;OU2=cnve;P=uni-erlangen;A=dbp;C=de I'net: mskuhn@immd4.informatik.uni-erlangen.de
eddins@uicbert.eecs.uic.edu (Steve Eddins) (06/11/91)
madler@nntp-server.caltech.edu (Mark Adler) writes: >The talk about JPEG being acceptable or not seems to imply that there >is a such a thing as "the" JPEG. There isn't. You can set the >compression level (roughly) by varying the quantization parameters >from no quantization (lossless decompression, up to round-off errors >in the DCT), to a great deal of quantization, the latter resulting >it really awful looking, blocky decompression (at about the 30:1 to >50:1 level). Setting these parameters is still rather a black art, >but up to a point, you have control over the resulting quality of the >decompressed images. >Mark Adler >madler@tybalt.caltech.edu A good summary, to which I would add the following comment: if lossless compression is what you want, the JPEG draft standard includes a lossless method based on DPCM and entropy coding (Huffman or arithmetic). This part of the standard does *not* use the DCT and incurs no round-off errors. According to the draft, you can expect 2:1 compression with the lossless coder for "typical" scenes (whatever that means). -- Steve Eddins eddins@brazil.eecs.uic.edu (312) 996-5771 FAX: (312) 413-0024 University of Illinois at Chicago, EECS Dept., M/C 154, 1120 SEO Bldg, Box 4348, Chicago, IL 60680
tgl@g.gp.cs.cmu.edu (Tom Lane) (06/12/91)
In article <1991Jun11.144958.4839@uicbert.eecs.uic.edu>, eddins@uicbert.eecs.uic.edu (Steve Eddins) writes: > [concerning the JPEG lossless mode] > This part of the standard does *not* use the DCT and > incurs no round-off errors. According to the draft, you can expect > 2:1 compression with the lossless coder for "typical" scenes (whatever > that means). That means 2:1 compared to an uncompressed full-color image (24 bits/pixel). To put this in perspective, here's some actual data for a small (205 x 250) full color image that I have handy. This would be about a factor of 4 smaller than a typical 640x480 image. Format # Bytes Compression full color uncompressed (PPM format) 150 Kb same passed thru Unix "compress" (enlarges file 9%) alleged performance of JPEG lossless spec 75 Kb 2:1 256-color GIF (made with PPM tools) 49 Kb 3:1 Lossy JPEG at "typical" quality setting 9.5 Kb 16:1 Lossy JPEG at "high" quality setting 16.5 Kb 9:1 (The JPEG lossless number is a guess based on the 2:1 ratio claimed in the spec; all the rest are actual numbers. Many GIFs are more like 4:1 or 5:1 smaller than full color equivalents, so this test case might be atypical.) Note that all but the GIF image are full color images; in my opinion the GIF image loses a good deal more, relative to the original, than either of the lossy-JPEG images. The quoted numbers for JPEG are based on Huffman coding; with the alternate arithmetic coding method, files are another five or ten percent smaller. There's some doubt as to whether you can use the arithmetic coding method without paying royalties to IBM, however. -- tom lane Internet: tgl@cs.cmu.edu BITNET: tgl%cs.cmu.edu@cmuccvma
madler@nntp-server.caltech.edu (Mark Adler) (06/12/91)
>> That means 2:1 compared to an uncompressed full-color image (24 bits/pixel).
If true, that's rather unimpressive, since I can get 2:1 just by
converting from RGB to YUV and averaging the UV pixels 4:1. I've
yet to notice the effect of this simple compression on a natural
image at normal viewing distance (four to six screen heights).
Mark Adler
madler@tybalt.caltech.edud88-jwa@byse.nada.kth.se (Jon W{tte) (06/12/91)
tgl@g.gp.cs.cmu.edu (Tom Lane) writes: > eddins@uicbert.eecs.uic.edu (Steve Eddins) writes: > 2:1 compression with the lossless coder for "typical" scenes (whatever > that means). That means 2:1 compared to an uncompressed full-color image (24 bits/pixel). We knew that. I believe the question was whatever '"typical" scenes' means ? A picture of an empty sea ? A forest ? The mandelbrot set ? The November '92 playboy foldout :-) ? There's some doubt as to whether you can use the arithmetic coding method without paying royalties to IBM, however. You can, as long as you stay away from their specific implementation (called the Q-coder) -- Jon W{tte h+@nada.kth.se - Speed !
d88-jwa@byse.nada.kth.se (Jon W{tte) (06/13/91)
> madler@nntp-server.caltech.edu (Mark Adler) writes: >> That means 2:1 compared to an uncompressed full-color image >> (24 bits/pixel). If true, that's rather unimpressive, since I can get 2:1 just by converting from RGB to YUV and averaging the UV pixels 4:1. I've Yes, but that's lossy. JPEG performs somewhat better when you allow it to be lossy... The 2:1 was for NOT lossy compression. You could still do better than that, methinks. -- Jon W{tte h+@nada.kth.se - Speed !
madler@nntp-server.caltech.edu (Mark Adler) (06/13/91)
>> Yes, but that's lossy.
Several people correctly pointed out that I was comparing apples
and oranges with the YUV vs. lossless JPEG 2:1 compressions. Bad
comparison. I guess my point was that 2:1 sounds low to me for
lossless natural image compression.
Mark Adler
madler@tybalt.caltech.edud88-jwa@byse.nada.kth.se (Jon W{tte) (06/13/91)
> madler@nntp-server.caltech.edu (Mark Adler) writes:
comparison. I guess my point was that 2:1 sounds low to me for
lossless natural image compression.
So what's a "decent" compression ratio ? Remember, GIF suffers
from a nasty loss in the 24-bit-to-8-bit transition (which also
is a 3:1 compression - at great cost)
I guess crawling along some space-filling curve and encode the
deltas for each color component using arithmetic coding could
do better sometimes, but that algo's "close" to the JPEG lossless.
--
Jon W{tte
h+@nada.kth.se
- Speed !knepley@mozart.cs.colostate.edu (Ranseus (Jim Knepley)) (06/13/91)
Just last night I found new compression program for GIF's. It's called GIFLITE (v1.0) and can compress GIF files up to 38% (in my tests) without any (read: none that I can see) loss of quality. Here's the wierd one, it's output is in GIF format. Sounds hard to believe, but it's true. I'll post it to a.s.p. hopefully after the weekend (I live over 75 miles from my news machine, so uploading is tough). If you can't wait that long and live in the Denver area, I got the program from Pinecliffe, GLITE10.ZIP. Also, could someone send me some posting software so that I don't have to split the file manually? Thanks in advance. -- ************************************************************************* Jim Knepley * Remember: Life is too short to watch knepley@handel.cs.colostate.edu * bad magic. *************************************************************************
madler@nntp-server.caltech.edu (Mark Adler) (06/14/91)
Jon W{tte (the left brace is actually some european character) wonders:
>> So what's a "decent" compression ratio ?
I'd say about 3:1 to 5:1, lossless. JPEG tacked on their rather hasty
and unimaginative lossless option late in the game. I have heard that
the JBIG (binary image) committee has decided to provide their own
lossless compression for gray scale images, even though that is outside
their charter and their name. This is in reaction to the poor performance
of the JPEG lossless option, and the rumor is that the JBIG method
will beat the pants off JPEG lossless. I consider this not at all
unlikely. (By the way, JPEG is simply three grey scale image compressions,
either lossless or lossy, usually in the YUV domain.)
Mark Adler
madler@tybalt.caltech.edulorenh@hpcvra.cv.hp.com. (Loren Heisey) (06/14/91)
> Just last night I found new compression program for GIF's. It's called >GIFLITE (v1.0) and can compress GIF files up to 38% (in my tests) without >any (read: none that I can see) loss of quality. Here's the wierd one, >it's output is in GIF format. Sounds hard to believe, but it's true. Version 1.2 of the program is on SIMTEL20 (ftp WSMR-SIMTEL20.ARMY.MIL or 192.88.110.20) and its mirror sites. Directory PD1:<MSDOS.GIF> Filename Type Length Date Description ============================================== GIFLTE12.ZIP B 43354 910608 GIF Lite v1.2, compresses GIF files -- Loren Heisey Internet: lorenh@hpcvra.cv.hp.com UUCP : {decwrl|rutgers|ucbvax}!hplabs!hp-pcd!lorenh