JPG desktop vs. mobile quality - same settings, different file size

[umlautnord]

Wondering if anyone has any intel on how Lightroom interprets the quality settings in the interface on desktop vs. mobile (iPadOS/iOS) for a jpg export. Exports from the mobile app are consistently a lot larger for the exact same jpg quality settings on desktop. All other file settings were the same.

For example, one photo at 90% quality: 2MB mobile vs. 1.1MB desktop. At 80% quality, the same photo: 1.2MB mobile vs. 686KB desktop. A different photo at 90% quality, 4.1MB mobile vs. 2.2MB desktop.

I've tried this with the source file in Lightroom being RAW, jpg, and HEIC. My only conclusion is that the quality % in the export dialog is simply translating differently on desktop and mobile into the actual JPG compression algorithm being used on the back end. I am curious if anyone knows anything specific about how they correlate, however, or has any other info on this.

(E.g. - is 80% mobile approximately equivalent to 90% mobile, with 90% mobile a higher setting than desktop will produce? It's definitely not an exact correlation. The settings are all pretty high quality, still, especially the 90s, so it's hard to get much distinction visually.)

It's a little strange that (ostensibly) the same software would produce something different from the exact same export setting, but I do recognize that mobile and desktop are ultimately different beasts. I also wonder if the resulting compression/quality numbers correlate with Classic settings in some way that I'm not familiar with. (My understanding is that some mobile users might be using the same mobile app, but using Classic on desktop rather than cloud-based Lightroom.)

Using iPad 11" 2nd gen, iPadOS v17.3, Lightroom v9.1.0; Desktop MBP 2020 M1, MacOS v14.3, Lightroom v7.1.2.

[Jao vdL]

The engine used on mobile and on desktop should be exactly the same but the interfaces are very different as you probably found out and it is very hard to do the exact same settings in my experience. Different metadata inclusion can easily lead to a few 100kB difference. Difference could also be caused by working from a smart preview in one case and a full raw file in the other. If the settings are the same including what metadata gets included and you are working from the exact same file, I would indeed expect the file size to end up the same. 

[Jim Wilde · Accepted solution]

Agreed, Jao....I also would have expected the resulting file-sizes to be more or less the same. But in some brief testing, that doesn't seem to be the case.....I get almost identical results when exporting the same file with the same settings from LrC and LrM (usually 0.1MB difference), but the output from LrD is always smaller (and by varying amounts ranging from 1MB on a DNG captured on my iPhone in LrM, up to 5MB on a 32MP DNG). I've rechecked the settings and they are as near to identical as I can get, so I have no explanation for the LrD differences.

[Jao vdL]

Interesting. That must mean they use slightly different code which is surprising and I tried the same thing and indeed LrD is always a tiny bit smaller for exactly identical settings.

[umlautnord]

Glad it's it's not just me! It's good to hear the mobile sizes are matching up with LrC, at least. But agreed it's surprising.

I do wonder if it's the same actual engine, but Lr desktop is just interpreting the quality % input differently. From what I've read elsewhere, it sounds like those scales can be pretty arbitrarily translated into actual settings for the compression algorithm depending on the software? Still really strange that it wouldn't be handled the same across products, though. Thanks to you both for digging a bit, I appreciate it.

[Jao vdL · Accepted solution]

I would guess that the root cause for the difference in size is that they must be using different optimized codes for the different processor architectures. I was assuming they used identical code just recompiled but that might not be true. The scales should map onto the quantization levels in the jpeg compression reference code somehow but you're right that might not be consistent.