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.
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.
"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?
I 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.
I’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.
I 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.
I left JPEG a long time ago. I use PNG for all such images now.
Well, I must say I find this article very interesting. However, I’m afraid tests need to be performed using more than just one picture.
Maybe 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).
Yes, an interesting test. But editing an even moderately compressed JPEG is just not something one would do if one cared about image quality. 
“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!
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.
Snooze… PNG does a pretty job of compression, and I’m not really into lossy compression when I’ve archiving my digital photos.
Excellent. If only there were more reference pages like this. Thanks.
Cool 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.
Hi!
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.