From TFA:

> My understanding is that JPEGs don’t have lossless rotation by default, and that is true for sips as well.

This is incorrect. JPEG's can be losslessly rotated in 90 degree increments. See the -rotate option to 'jpegtran' in the libjpeg toolset.

https://man.archlinux.org/man/jpegtran.1.en

Best guess at what the author saw, the original files were likely originally compressed with an encoder that did not optimize the huffman table, and his newer tools likely do compute an optimal huffman table for compressing the DCT coefficients, that and the fact that the author was doing a lossy recompression would often result in file size reductions.

Also, passing jpeg's through jpegtran's lossless '-optimize' option often shrinks them in size. I.e., the jpeg's direct from most cameras often shrink (sometimes substantially) when optimizing them this way.

It's possible to get slightly better compression by losslessly rearranging data in a JPEG (DC components are compressed row by row, and prefer fewer horizontal color changes).

However, here the author seems to accidentally fully recompress the images, and falls into the classic trap of "looks almost the same but the file is much smaller!"

That's what every lossy format does every time. They're designed to lose data that is hardest to see with the naked eye.

At the top end of the quality range, file sizes grow exponentially in proportion to quality (it's natural consequence of allowing less and less data to be lost, and approaching lossless compression that has a hard limit on how effective it can be).

But conversely this means that going from very high quality to still-pretty-high quality moves the file size along the exponential curve and seems to give dramatic reduction in file size. This isn't any trick, that's how it works.

File size change is easy to measure, but visual quality change is difficult to quantify, so people disregard the visual change. In reality they're just moving a point along a curve, and recompression gets a worse curve (less quality for the same file size) than the quality-to-file-size ratio of compressing the file at the lower quality from the start.

I've always wanted a tool to rotate and crop jpeg images on tile boundaries so no loss happens. This limits how precise a crop can be, but preserves pixels perfectly. Is there a tool like this?

Note that JPEGs can be rotated without decompression, just by swapping the axes of the compression cells.

Some of the software he uses may do this, others may decompress, rotate and recompress.

Not really surprising, given that the original image seems to be compressed very conservatively:

    13,290,914 original.jpeg

    15,357,049 magick-q99.jpg
    13,323,544 magick-q98.jpg
    12,197,196 magick-q97.jpg
    10,745,457 magick-q96.jpg
     8,577,000 magick-q95.jpg
     7,933,287 magick-q94.jpg
     7,360,975 magick-q93.jpg

    15,386,195 magick-rot90-q99.jpg
    13,325,385 magick-rot90-q98.jpg
    12,115,271 magick-rot90-q97.jpg
    10,733,896 magick-rot90-q96.jpg
     8,661,101 magick-rot90-q95.jpg
     7,962,175 magick-rot90-q94.jpg
     7,343,580 magick-rot90-q93.jpg

Here all `magick-[rot-]qXX.jpg` files come from `convert original.jpeg [-rotate 90] -quality XX magick-qXX.jpg`, where my ImageMagick version is 7.1.1-12 (Windows x86-64, Q16-HDRI). The initial shrinkage is solely from the lossy compression process and doesn't depend on the rotation angle that much.

Using EXIFTOOL rotate flag… would this work, as in losslessly rotate the JPG file?