Making Photos Smaller Without Quality Loss

I don't know it's fair to assume quality means theoretical quality over perceptual quality in this context. They took the time to make sure perceptual quality was quantitatively consistent, so they get a pass in my books.

I'd be angry, however, if they used the word "lossless", as that implies no _information_ is lost.

You're also overlooking the fact that they did some relatively interesting things to notice when someone posts a PNG-of-something-that-could-be-a-JPEG, and can then use a lossy image instead of the larger PNG.

Exactly my thought too. A while ago Dropbox had an article about how they optimized images while making sure the output is bit-for-bit identical.

Link: https://blogs.dropbox.com/tech/2016/07/lepton-image-compress...

You misread the article. Setting the JPEG quality is their starting point. He then goes on to describe reducing size from that starting point without further quality loss.

Granted, initial reading of the title might lead you to assume he means "from upload quality", but I don't think it's intentionally misleading.

i see literally no difference between all of these. i've stared and flipped through them for a minute.

All of them cause noticeable quality loss to the orange anthers of the flower in the top left.

Data transfer is cheap. If they used webp savings would be even significant.

Data transfer for a mobile user is not that cheap, thats more important.

Were any of your patches accepted?

Pillow has had some significant changes in the resampling filters in the last year or two, both in correctness and speed.

(PIL is dead. last release was 10 years back)

Because it's HORRIBLY slow. Mozjpeg is actually usable for on-the-fly processing, you can run it right in a request handler. Guetzli is waaaay too slow.

(author here), It wasn't available when I started this project. butteraugli was (which guetzli uses internally), but in my opinion they're relatively new and need a bit more rigorous review than I can provide. I ultimately chose SSIM not because it was the most accurate metric in all cases, there have been plenty of advancements since it was published. But I linked a paper comparing several alternatives and saw that SSIM works fine for this use case (all things equal except number of JPEG artifacts), while being much faster, and that was enough proof for me to keep it simple.

In a batch scenario today, one of these could make sense instead of SSIM and/or mozjpeg, but definitely do your own comparisons at equivalent file sizes, required reading: https://kornel.ski/en/faircomparison

We do set a pretty high lower bound to avoid the edge cases inherent in the algorithm and as a result, out of the 30% savings, dynamic quality was only a small portion of that. I wouldn't be surprised that with an offline workload, a more CPU-intensive algorithm can do much better with a lower lower bound.

I found that SSIM scores for images were relatively stable across resolution (same general graph shape, just translated down on the Y-axis). This is mentioned at line 36 of the example dynamic quality code. So we actually generate, compute and compare the SSIMs on much lower resolution candidate images than the final image for speed as well. I'm not sure if this would hold true for something like butteraugli to help open up the possibility for more real-time workloads.

They're working with photos, PNG is not really useful for photos, the DEFLATE algorithm doesn't work with "noisy" data.

Yes, it's one way of storing the image data in a single JPEG file. It doesn't need multiple files and it doesn't need any extra code. It's usually only visible when you're loading the file over a slow link. Old software might not show the intermediate steps from the file but they should still be able to display the image once it's 100% loaded.

Back in the days of slow internet access, nearly every non-animated image was a jpg and loading from blurry to clear was the norm. It's part of the file format.

> What is Pillow

A Python library for manipulating image, like ImageMagick and the like.

> so loading a small version spread out to full size with blur, then in the background loading full size copy to replace blurred small image, that is not progressive loading…?

Progressive JPEG is closer to refinement of previous blocks, it doesn't "add blur", it starts with smaller less precise blocks then refines them. Progressive jpeg actually tends to be smaller than non-progressive (as opposed to e.g. progressive PNG)

> Edit: also is progressive loading something that happens once or does a script have to do that every time the photo is pulled?

There is no script, progressive JPEG is part of the core spec.

Pillow is a fork of PIL -- the Python Imaging Library -- which had become unmaintained ('PIL' is in 'pillow'). It's the go-to image manipulation library on Python.