programming and human factors
by Jeff Atwood
Over the years, I've standardized on a JPEG compression factor of 15; I find that generally provides the best compromise between image quality and file size for most photographic images.
Although I've done some ad-hoc testing that pointed to compression factor 15 as the sweet spot before, I've never done a formal test. So I performed a JPEG compression series using the Lena reference image*. Note that I resized the image slightly (from 512x512 to 384x384) to keep the file sizes relatively small. The original, uncompressed image size is 433 kilobytes.
| compression factor 10 (39 kb) | compression factor 15 (30 kb) |
| compression factor 20 (26 KB) | compression factor 30 (16 KB) |
| compression factor 40 (11 KB) | compression factor 50 (9 KB) |
Beyond 50 percent compression factor, quality falls off a cliff, so I won't bother displaying anything higher. Here's a more complete breakdown of JPEG compression factor and file size for the 384x384 Lena image:
I was also curious what the image quality and file size penalty was for recompressing a JPEG image. That is, opening a JPEG and re-saving it as a JPEG, including all the artifacts from the original compressed image in the recompression. I've been forced to do this when I couldn't find an uncompressed or high quality version of the image I needed, and I always wondered how much worse it made the image when I recompressed it.
For the recompression test, I started with the uncompressed, resized 384x384 Lena reference image. For each new generation, I opened and saved the previous generation with my standard JPEG compression factor of 15.
| Generation 1 (30kb) | Generation 2 (30kb) |
| Generation 3 (30kb) | Generation 4 (30kb) |
| Generation 5 (30kb) | Generation 10 (30kb) |
I was quite surprised to find that there's very little visual penalty for recompressing a JPEG once, twice, or even three times. By generation five, you can see a few artifacts emerge in the image, and by generation ten, you're definitely in trouble. There's virtually no effect at all on file size, which stays constant at 30-31 kilobytes even through generation 15.
* An entire set of classic reference images is available from the USC-SIPI image database. I distinctly remember that Mandrill image from my Amiga days.
The main complaint I've got about "standardizing" a compression level for JPEGs and just blindly using it is that JPEG doesn't provide uniform distortion across all channels of the RGB color spectrum. On very red images with broad areas of color, JPEG looks very muddy at even low levels of compression. It's also an extremely harsh way to compress line art, suitable only as a last resort.
ChrisE on July 9, 2006 6:03 AM"very little visual penalty for recompressing a JPEG once, twice, or even three times. "
I think it's similar to zipping a zip file. All the compression that can be done has been done. Maybe the algorithm is smart enough to realize that.
Now, you can achieve a little bit of extra compression with archive files if you use another algorithm. Say bzip a tar file or rar a zip file and they get a little smaller. Have you tried converting a PNG to a compressed JPEG or vice versa?
Scott on July 9, 2006 10:09 AMI think it's similar to zipping a zip file.
Not really, because this is *lossy* compression, whereas ZIP is *lossless*. Every JPEG recompression loses more and more of the original data.
But evidently the JPEG algorithm is fairly tolerant of its own artifacts, eg, it was designed to allow recompression of previous JPEG images without losing too much additional data.
Anyway, I was definitely impressed how good the 2nd, 3rd, and 4th generation copies looked. It far exceeded my expectations.
Jeff Atwood on July 9, 2006 10:43 AMI'm currious as to what factors you considered to settle on your sweet spot. Considering the fact that the cost of storage has been falling at such a fast pace for the past 20 years, it would seem you would have to re-analyze the sweet spot every year or so.
Greg Miller on July 10, 2006 8:33 AMI think your conclusion about recompression is only valid for the very specific test you performed. Other cases might be significantly worse.
AIUI, JPEG encodes brightness information separately from hue, with the former being at a relatively high resolution and the latter being lower resolution. To do this it needs to overlay the image with a logical grid, subdividing into small regions that will share the same hue information.
If your re-compressed image's grid happens to fall on exactly the same pixels, you'll get the results you describe. And this will be the result using the same software on an unedited image. But if you crop the image, or possibly use different software for encoding, then the regions will fall on different pixels.
If you reencode this way, the lossiness of the algorithm will very quickly multiply its own errors, and you'll get unacceptable results in a much lower generation number than you observed.
It'd be nice to see a comparison with JPEG2000, although I suppose it's generally just a fun exercise, since most computers don't have a JPEG2000 codec available.
Jeremy on July 10, 2006 9:59 AMWell, I must say I find this article very interesting. However, I'm afraid tests need to be performed using more than just one picture.
Lautreamont on July 10, 2006 10:34 AMMaybe I'm just nitpicking, but I can tell a strong difference between the "compression factor 10" and the "compression factor 15" pictures.
It is possible that it is an artifact of my browser, my monitor, etc., but the "10" looks relatively lifelike, and the "15" looks flat and posterized.
Yet, the "15" may be "good enough for the web." In this, I agree with ChrisE, it depends upon the original picture, but, I would add, it also depends upon the intended audience. If you were to take some of the pictures on Worth1000, the *believability* would be lost with compression. But, most political blog pictures could have a great deal of compression ("50" or more) without losing the intended effect (since the effect is not the picture itself, but the context the picture adds).
Izzy on July 10, 2006 11:30 AMYes, an interesting test. But editing an even moderately compressed JPEG is just not something one would do if one cared about image quality. :P
"I left JPEG a long time ago. I use PNG for all such images now." That's great...if you are not worried about bandwidth or disk space. At higher quality settings (lower compression settings) the same image saved as PNG is still notably larger than a JPEG image.
My philosophy? Image formats, like programming languages, are tools. Use the right tool for the right job. There is no magic, universal tool to do all jobs.
I'm currious as to what factors you considered to settle on your sweet spot.
This is only for images to be displayed on web pages. For archival storage, obviously you'd go with some kind of lossless format like PNG, or TIF, or even RAW.
However, I'm afraid tests need to be performed using more than just one picture.
Of course. This is just an off-the-cuff basic test for some broad guidelines. I've seen far too many JPEGs with horribly inappropriate compression levels. Usually the compression factor is too low (1..5), producing extremely large images, when they could have set it to 10 or 15 at almost no visual difference and reduced their bandwidth usage by one-third!
Excellent. If only there were more reference pages like this. Thanks.
Max on September 23, 2006 1:15 PMCool research! I personally always switch from JPEG level 10 to 20 and back. :)
I found an interesting calculator which gives an estimation of JPEG file size based on frame resolution and JPEG compression level.
http://www.jvsg.com/bandwidth-storage-space-calculation/
Actually this tool is made for CCTV, but it was interesting to see how the compression affects the frame size for different resolutions.
Josef F. on September 7, 2008 8:19 AMHi!
I need a matlab code for jpeg compression. Can you help me?
I think it's interesting that 0% compression still looses information.
Jpeg should be abandoned.
Philip on March 17, 2009 7:28 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |