Does JPEG-to-JPEG export Lightroom reapply compression?

Question

I want to crop a JPEG file in Lightroom and export that cropped file to another JPEG so that I can e-mail it. The exported JPEG should have the same quality as the original. I don't have the RAW file available anymore.

When I export the file I choose JPEG as an export format. But now I'm wondering if I should set the quality to the same quality as the original JPEG (= 80), or to 100.

I'm not sure if Lightroom reapplies the compression to the JPEG, i.e.:

RAW -> compress to quality 80 -> JPEG file 1 -> compress to quality 80 -> JPEG file 2

Or that it decompresses the JPEG and recompresses it again, effectively giving the same quality:

RAW -> compress to quality 80 -> JPEG file 1 -> decompress to bitmap -> compress to quality 80 -> JPEG file 2

How does Lightroom handle this?

Answer 1

The image will be recompressed. The two scenarios you describe are actually effectively the same, because the lossy part of the JPEG compression discards information which stays gone when the image is decompressed. (Hence, lossy.) That means that reapplying with the exact same parameters shouldn't do much, either in terms of further space saves or in terms of further artifacts. The differences come down to precision and rounding errors. (This is the same in Lightroom as it is in any other program.)

So, if you recompress with exact same parameters and have aligned your crop to 8×8 blocks, the degradation should be minimal. However, if you're using a high level of compression (I think 80% qualifies), you might actually see a difference, because the artifacts introduced by the initial compression are permanent changes to the image and will get recompressed too, possibly causing more artifacts.

Setting to 100 will be more safe, as any newly added artifacts will be hard to notice. It won't make the image any better, but not significantly worse. However, it will introduce changes across the whole image, whereas resaving will mostly concentrate changes to where artifacts are already noticeable. This, unfortunately, means that your mileage will vary.

If you're resizing or have made significant manipuations, all bets are off.

As a quick test, I used ImageMagick to recompress a JPEG image over and over at 75%. The samples below are uploaded as PNG files to avoid yet further recompression, and were doubled in size when I converted to PNG to make the effect more obvious. It turns out that after eight resamplings, the effect converged on a perfectly stable result, where recompressing again results in a bit-for-bit identical file.

Here's the uncompressed original:

Here's the result of going to 75% JPEG:

And here's that resaved:

Woah; that's actually much more noticeable than I expected, and I work with JPEG all the time.

So here's the final converged image (8th pass):

Again, colors are definitely even more off, including some false color patterns, and the blocky artifacts jump out more. So, don't do that.

But here's the same thing after 9th passes (the point where it converges) with a 99% quality level:

Here, the difference barely registers. (I mean that literally; compare them pixel by pixel to the non-compressed version and the deviation is just very slight random noise.) So, what if I go back to that first 75% image and then resave at 99%? Well, this, (after just once):

That's definitely visibly better than resaving as 75% again, kind of to my surprise. But, there's obvious new degradation around the pink trimming and the eyes. With the recycled version of the same settings, the JPEG artifacts are being exaggerated with each recompression. With the low resolution and low quality I've chosen, that turns out to be worse than recompressing everything differently.

But, it's also worth mentioning that saving 75% one time is much worse than resaving at 99% a million times. In my example case, the artifacts at 75% are so obvious that the further degradation is like dumping water in the ocean. If you save at a high enough level that these artifacts are not really visible, then my original advice (same settings, will yield basically the same result) still applies. Of course, if you can stick to always working from uncompressed originals, you're better off.

If you can't, I'd try it both ways and see what looks better for your particular image.

Answer 2

As Mattdm said, JPEG is an image format that will loss its quality after each re-saving. This is a price that we pay for the resulted small image file size.

But JPEG also allows some loss-less operation including, Rotation (90, 180, 270 degress), Flipping (Horizontal or Vertical) and Cropping . Not sure whether LR allows to save JPEG images loss-lessly, but there are some third party tools that allows it, for example: FastStone Image and BetterJpeg.

A minor drawback: when cropping lossless, images of sizes which are not a multiply of the JPEG block (16 × 16 pixels for color images, 8 × 8 pixels for grayscale images) have to be cropped to the block boundary, which is mostly not exact there where you have selected.

Answer 3

So how it works in theory?
First, when you hit save button, there is conversion between RGB to YCrCb color system. If you implement this badly, here is your first step of data loss. There are practical reasons why this conversion is needed but it not crucial here. After this conversion, from every pixel value is subtracted value of 128 to create zero-mean image.
After conversion RGB to YCrCb is finished, you image is divided in blocks of 8x8 pixels, which are called blocks, or MCU (minimal coded unit). After your image is divided in 8x8 blocks, then Forward Descreete Cosine Transform is executed on every 8x8 block. Formula of FDCT is given bellow:

where M and N are dimensions of the 8x8 block, in our example M=N=8, and C(u), C(v) are constants which is given in picture bellow:
"

F(u,v) is result of FDCT, which is also matrix/block 8x8 pixels, and F(u,v) elements are called FDCT coefficients, and they are frequency representation of the picture. First element F(0,0) is called DC coefficient, and others are called AC elemts. First element is most important because it hold most of data of 8x8 block. If we do some math we can get that first element F(0,0) is mean value of all other nodes, multiplied by 8 which is described in formulas bellow.
and you get

Enough of mathematics :).
If you are following me, then you see that we didn't loose so much data until now (we can still run IDCT (I-inverse) and we will get our starting image with some losses). So where is the process, what is changing when you are setting your Photoshop/Lightroom quality size when you are saving .jpeg image? Let's continue.

So lets say we have image 16x16 pixels. When we divide our image to 8x8 blocks, we get two 8x8 blocks. After we do color conversion, we get to FDCT. We run FDCT on first 8x8 block, and as resoult get new 8x8 block, which is product of FDCT. Then we run FDCT on second 8x8 block of original image, and as result, we get another 8x8 block of FDCT. So altogether, result of FDCT on our 16x16 picture/matrix is new 16x16 matrix and lets call it F matrix.

Now F matrix is divided in 8x8 blocks, and it is divided with quantisation table which is matrix of 8x8 pixels. Quantisation table values are constants/numbers which are given by experimental results on human eye. Classical quantization table is given bellow.

This matrix which is called Q matrix, is divided with our F matrix, actually first 8x8 block of F matrix, then with second 8x8 block of F matrix, and so on. Why? To get smaller numbers, for which we need fewer bits to represent them in digital file. If you have value 105, you need 8 bits for digital representation. But if you devide 105 with 52, then you get 1,90. You take only integer part, which is 1.00. Representing decimal number 1 you need one bit only, so you saved 7 bits. Now imagine savings for picture with 4000x4000 pixels :).

This process of dividing F table with Q table is spot where jpeg loss is happening. If Q elements are bigger, loss is bigger and vice versa. So when you changing Photoshop spinner from bad to great quality, actually you are changing values of Q table.

Also, you see that first element of Q matrix, Q(0,0) is smallest one. It is because this element will bi divided with F(0,0) element, which is DC element (element which holds most of data), and if we divide it with big number, you will see 8x8 blocks in your image, as you can see it in pictures posted by @mattdm.

Your answer is yes it is :)

I hope I helped you :)