
Making Photos Smaller Without Quality Loss - WhiteOwlLion
https://engineeringblog.yelp.com/2017/06/making-photos-smaller.html
======
ggambetta
"MAKING PHOTOS SMALLER WITHOUT QUALITY LOSS"

 _proceeds to explain how they set JPEG quality to 80-85%_

~~~
gknoy
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.

~~~
WhitneyLand
How is this a big mystery isn't pretty much everything that's user generated
content a photo and everything that's a logo or brand not a photo?

~~~
abritinthebay
Read the article. Short answer: no, while your image content breakdowns are
accurate it's not actually that simple in practice as things like screenshots
are pngs.

------
vladdanilov
SSIM being a global metric is not sufficient for many cases. Images with soft
gradient tend to be overcompressed.

MozJPEG is a good improvement. But its trellis cost model causes noticeable
blurriness on fine details [1]. Compare with the original [2], Guetzli [3] or
my Optimage [4].

So, 'Without (Visual) Quality Loss' is such a stretch.

[1] [http://i.imgur.com/6naOWSf.jpg](http://i.imgur.com/6naOWSf.jpg) [2]
[http://i.imgur.com/jny5miJ.jpg](http://i.imgur.com/jny5miJ.jpg) [3]
[http://i.imgur.com/gkO2HsP.jpg](http://i.imgur.com/gkO2HsP.jpg) [4]
[http://i.imgur.com/GEshKJD.jpg](http://i.imgur.com/GEshKJD.jpg)

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

~~~
khedoros1
The biggest difference that I see is that the leaf veins are clearer in the
original image than in the other three, and that the MozJPEG one _did_ lose
some of the finest details.

------
js2
Similarly at Flickr a couple years ago:

[http://code.flickr.net/2015/09/25/perceptual-image-
compressi...](http://code.flickr.net/2015/09/25/perceptual-image-compression-
at-flickr/)

As well as other changes to reduce storage costs:

[https://code.flickr.net/2017/01/05/a-year-without-a-
byte/](https://code.flickr.net/2017/01/05/a-year-without-a-byte/)

------
mbesto
> This adds up to an average image file size reduction of around 30%, which we
> applied to our largest and most common image resolutions, making the website
> faster for users and saving terabytes a day in data transfer.

I love these type of endeavors because the ROI is pretty clear. So what's the
costs ($$) savings?

~~~
tehlike
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.

------
mark-r
When I looked at the code for PIL a few years ago, the part I was looking at
(resizing) was a real mess with some significant bugs. Has Pillow gotten any
better?

~~~
markdown
Were any of your patches accepted?

~~~
mark-r
I never bothered, because 1. PIL appeared to be stagnant, 2. without being
part of the community I could easily make breaking changes since I judged the
existing behavior to be incorrect, and 3. I had other things to do. I have
seriously considered going back to see if there's anything I could contribute
- I haven't looked at it in years, and it would take a while to identify the
code I had looked at before.

------
dabber
Hmm, I'm behind a popular VPN and get greeted with:

"Sorry, you’re not allowed to access this page."

"Contact Yelp if you keep experiencing issues."

Oh well

------
WhiteOwlLion
Why not use Google's Guetzli to compress JPEGs?

~~~
floatboth
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.

~~~
dawidloubser
Agreed. As a photographer, I use and love Guetzli, and it offers a bona fide
size reduction of more than 30% over typical JPEG compression algorithms at a
similar visual quality level.

But it's extremely computationally-intensive, taking over a minute to compress
a single web-resolution image on my i7 laptop.

I can't see it being practical in a high-volume server scenario.

------
discreditable
I'm surprised they didn't try losslessly optimizing PNGs with optipng and
advancecomp. Optipng in particular can result in some pretty significant size
reductions in my experience.

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

~~~
discreditable
They specifically mentioned that they have PNGs of logos that they avoid
converting if they're <300kb. Optipng would work well on the images that they
keep in PNG format.

~~~
floatboth
They should try just compressing them with mozjpeg anyway, since mozjpeg has
deringing
[https://calendar.perfplanet.com/2014/mozjpeg-3-0/](https://calendar.perfplanet.com/2014/mozjpeg-3-0/)
it's actually not bad for text/cartoons/other things with high-contrast edges

------
kemonocode
It took me a shameful amount of time to realize the peppered 400: Invalid
request's through the article were unintended.

------
acranox
I think that photo of a "donut" is actually a bagel.

------
ge96
What that's what progressive means... where do you select that, is that
something you select in say GIMP?

>Progressive JPEG images load from more blurry to less blurry. The progressive
option can easily be enabled in Pillow

What is Pillow, Python... hmm... 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...?

If I was looking into progressive loading... and implemented a CDN... can this
still work? Is it python specific? I use PHP for scripting... maybe an excuse
to actually build something with Go rather than the hello world examples.
(assuming you can use Go)

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

What is this a support forum? haha calm down kid

~~~
masklinn
> 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.

~~~
WhiteOwlLion
If we had progressive JPEG for all JPEGs, low bandwidth networks could request
a percentage of the file and save on total data needed to render a page. This
could be useful for areas where 2G may be the norm.

~~~
Negitivefrags
In this age of devices with different DPI and pinch-to-zoom it would be nice
if the browser would only get as many progressive levels as required for the
current display resolution of the image.

