[Tom]

TLDR.  When you compress a JPEG multiple times using a well behaved encoder, most of the visual loss occurs in the initial compression (due to use of lower quality setting, chroma sub-sampling, etc).  However, issues may arise in encoders that are not well behaved.  YMMV!

Most of us are aware that JPEG compression is lossy.  When you open and re-save a JPEG it's akin to copying a cassette tape.  Because of this, most of us are careful to work from originals when processing photos and save the output as a copy or in a lossless format.

But what happens if you compress in a lossy format "too many" times?  I recall seeing this writeup a few years ago:

https://petapixel.com/2016/04/06/happens-resave-image/

Looks scary!  Will your images grow horns?  Will a kitten die each time you re-compress a JPEG?  I decided to find out (don't worry, no kittens were actually harmed).  Here is a JavaScript utility I put together to re-compress images multiple times in browser.  You can pick an image from your device, or use the sample image provided.

https://nwhikers.org/tests/recompress.html (click compress, then drag vertical slider to compare to original)

Why did I bother to do this?  Well, I was curious what quality setting was "close enough" to lossless, such that saving 100x would not make a difference.

Photo credit: sample image was cropped from this magnificent photo posted by awilsonc:

Oregon Coast Sunset © awilsondc

It important to note that Firefox, Chrome, Safari, etc. compress JPEG differently so YMMV!  Also, browsers will compress JPEG somewhat destructively in just 1 compression at quality < 90%.  To see this, set the quality to 80%, and select 1x compression, then hit the compress button.  You will see the sunburst in the sample image lose a lot of its brilliance after just one compression.  Why is this?  Well, browsers sub-sample chroma (color) below quality 90%.  In fact, Chrome and Safari sub-sample crhoma unless you save at quality 100 (which is pretty ridiculous)!  Perhaps they listened too hard to this guy:

https://calendar.perfplanet.com/2015/why-arent-your-images-using-chroma-subsampling/

To be fair, most images aren't impacted that much by chroma sub-sampling, but it's important to point out.

Now change the encoder option from browser to pettiojpeg (results should be similar for all browsers) and do a single compression.  Voila the sunburst doesn't lose its brilliance!  This is because pettiojpeg doesn't sub-sample chroma above quality ~50%.  However, the filesize is noticeably larger.  It's a tradeoff between quality and size.

Now that we have that important distinction out of the way, test with quality 90 or higher in Firefox.  Why Firefox?  Well, Firefox doesn't apply chroma sub-sampling at quality 90% or higher, so you're going to get apples-apples comparison to the original.  Compress the image 100x and see what happens.

Surprised?  The compression becomes lossless after a certain number of compressions.  Now compare the last compression to the original.  They look identical to me, even at 200% crop.  That said, my eyes aren't what they used to be...

Now change the compression to pettiojpeg and set quality to 90% or higher.  Holy cow, what's going on?  What are these weird blocks showing up after a dozen or so compressions?  To be honest, I don't know.  I know that compression is done by breaking the image into small blocks and averaging them, which creates artifacts, but at higher quality there should be few artifacts.  Now, try it again with quality 80%.  The blocks go away.  Whoa!  This is somewhat counter intuitive.  Going back to the "cassette tape" analogy we'd expect higher quality copy to equate to less degradation. but with lower quality compression we actually see a better end result, perhaps due to the compression being lossless after 13th compressions?

pettiojpeg compressed 100x at quality 92%, then compressed at quality 80% (mozjpeg)

pettiojpeg compressed 100x at quality 80% (lossless after 13 compressions), then compressed at quality 80% (mozjpeg)

Now test in desktop Chrome.  The weird blocks don't manifest and multiple compressions don't materially impact image quality, at least not beyond any chroma loss in the first compression.  I don't have any Apple devicdes so am unable to test Safari.

For grins I decided to test in mobile Chrome (on my tablet) at quality 99% and 100%.  Yikes! The test image got destroyed, but differently than pettiojpeg.  At lower quality settings the issues go away, similar to pettiojpeg, so it's not just pettiojpeg that doesn't play nice with multiple compressions.

I also decided to run a test using ImageMagick which is what we use to resize and thumbnail images on our server.  At lower quality settings the sample image gets destroyed, but check out quality 90%, it's the worst!  That said, at quality 92% the issues go away.

ImageMagick compressed 100x at quality 90%, then compressed at quality 80% (mozjpeg)

ImageMagick compressed 100x at quality 92%, then compressed at quality 80% (mozjpeg)

I have to think this is some sort of precision error that gets duplicated, but it is a little concerning that some encoders don't behave very well with multiple compressions of the same image.  For sure I'll avoid quality 90% in ImageMagick, even for a single compression, call me paranoid now.

So what's the takeaway?  Well, it seems to me that multiple compression isn't as bad as we are led to believe, at least not if using a well behaved encoder.  Using Firefox as an example, you don't really lose much after the first compression (if at all in the first compression at 92% quality).  Yes, some encoders do weird things with with multiple compression, but that seems to be an issue with the encoding algorithm than lossy compression in and of itself.

[InFlight]

Most photo printing is 300 dots per inch.
So a 6” x 4” print is-
6 x 300 = 1800 pixels
4 x 300 = 1200 pixels
Thus 2.16 Mega Pixels

Even a cropped picture taken with any modern camera over 20 Mega Pixels is compressed significantly for photo printing.

I’m not suggesting that repeated reduction is a good practice.  But normal photo prints are a very significant reduction and still look good.

[GaliWalker]

I only do the single jpeg conversion (from RAW), but still...very cool! 

[neek]

Looks like a punch card.  Check this out though.  I went through every quality level (from 1-100, using ImageMagick on the command line, so it was quick), and this ONLY happens with quality between 80 and 90 (inclusive).  At all other levels, the file (like, the actual md5sum) stops changing after a few iterations, and there's no visual difference between the first and final iterations.  Weird huh?  So the audiotape analogy does kinda work between 80 and 90.  For ImageMagick anyway.