{"id":21505,"date":"2017-04-03T18:20:23","date_gmt":"2017-04-03T18:20:23","guid":{"rendered":"http:\/\/a_closer_look_at_guetzli"},"modified":"2025-03-09T12:04:38","modified_gmt":"2025-03-09T19:04:38","slug":"a_closer_look_at_guetzli","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/a_closer_look_at_guetzli","title":{"rendered":"A Closer Look at Guetzli, Google\u2019s New JPEG-Encoder"},"content":{"rendered":"
\"\u201cGuetzli\u201d\n

(Photo by Erol Ahmed<\/a>)<\/small><\/p>\n

A few weeks ago, Google officially announced<\/a> a new JPEG encoder, called Guetzli<\/a>.<\/p>\n

Cloudinary has been tracking Guetzli since it was soft-launched<\/a> in October; it has been amazing to watch news about it bubble up into the pop<\/a>–tech<\/a> press<\/a>.<\/p>\n

The popular take: Guetzli is an ingenious, Google-backed shot in the arm for the dusty\/trusty old JPEG format, which \u2013 if you\u2019re willing to wait for its extremely<\/em> computationally intensive algorithms \u2013 produces JPEGs that are 35% smaller (or better) than was previously possible.<\/p>\n

Has Google managed to squeeze blood from a stone? I\u2019ve been running some tests to find out; the truth is more complicated, nuanced, and, I think, interesting. Read on!<\/p>\n

Butteraugli Brains<\/h2>\n

Lossy encoders throw data away. Good ones do so artfully, so that we don\u2019t notice. A well-encoded lossy image will look just like the lossless original (to our fickle<\/a> yet fallible<\/a> human eyes), despite containing a fraction of its information.<\/p>\n

Imaging R&D is most-reliably guided by real-world experiments, in which real people are really asked what they subjectively notice. There are many (many) situations where that kind of testing is impossible, though, and you need an objective, mathematical model that estimates subjective \u201cquality.\u201d<\/p>\n

For decades, the image quality metric of choice was PSNR<\/a>: a tidy piece of information theory which measures the signal<\/em> of the original against the encoder\u2019s lossy artifacts, or noise<\/em>.<\/p>\n

In 2004, a handful of researchers introduced<\/a> a new, arguably better, model: SSIM<\/a>. SSIM was built on a few key insights about some high-level perceptual concepts. Turns out, we pay special attention to patterns and \u201cstructures\u201d (and often ignore the really bright bits of an image).<\/p>\n

Guetzli\u2019s raison d\u2019\u00eatre<\/i> is a brand new metric for image quality, developed by researchers at Google, called Butteraugli<\/a>.\nButteraugli takes modeling the complicated and particular ways that our biological systems actually work<\/em> to a new level: cells in the retina<\/em>. Its project description includes the phrases, \u201clow density of blue cones in the fovea\u201d and \u201cmore accurate modeling of ganglion cells,\u201d for goodness sake!<\/p>\n

Butteraugli is brand new, largely untested, and really interesting. It\u2019s the brains behind Guetzli.<\/p>\n

Binary Search Brawn<\/h2>\n

In most encoders, when you select a \u201cquality\u201d at encode time you\u2019re picking an integer between 1-100 that the encoder\u2019s designers have arbitrarily mapped to a set of arcane technical parameters. As a result, encoding with a \u201cquality\u201d of 86 doesn\u2019t mean that the resulting JPEG will be \u201c86 percent good\u201d in any objective or portable way. Photoshop\u2019s 86 != libjpeg\u2019s 86<\/a>, and even with the same encoder and input quality, output<\/em> quality, as measured by metrics like Butteraugli or SSIM, will vary from image to image.<\/p>\n

Cloudinary\u2019s q_auto<\/code><\/a> tries to do better. q_auto<\/code>\u2019s four quality levels (:best<\/code>, :good<\/code> (the default), :eco<\/code> and :low<\/code>) don\u2019t map to specific sets of arcane encoder settings \u2013 instead, via heuristics, a trial encode or two, and some quick checks with a custom SSIM metric, q_auto<\/code> dials up custom encoding parameters for every image, tailoring them to fit each image\u2019s unique compression characteristics. q_auto<\/code> lets you select an output<\/em> quality. A q_auto<\/code> image will always look good<\/em>; a q_auto:best<\/code> image will always look great<\/em>.<\/p>\n

Guetzli takes this idea to its logical extreme. When you select a Guetzli quality, what you\u2019re actually selecting<\/a> is a specific Butteraugli score; Guetzli then does dozens<\/em> of full encodes, methodically dialing parameters up and down and measuring the results, until it achieves that precise score.<\/p>\n

This stubborn precision, more than anything, is what makes Guetzli so slow. Which brings me to my next point.<\/p>\n

Strong Opinions<\/h2>\n

Guetzli is a very focused, opinionated piece of technology, I found this out the first time I ran it:<\/p>\n

$ guetzli --quality 80 original.png guetzli.jpg\nGuetzli should be called with quality >= 84, otherwise the\noutput will have noticeable artifacts. If you want to\nproceed anyway, please edit the source code.\nGuetzli processing failed\n<\/code><\/pre>\n
\u201cPlease edit the source code\u201d! The sass!<\/p>\n
The second run threw me, too: I\u2019d heard it was \u201cslow,\u201d but encoding a one-megapixel image ate up 300 MB of RAM and took a minute and a half<\/em>. Mozjpeg<\/a> completes the same task in 300ms.<\/p>\n
The Guetzli folks have explained the limited quality range<\/a>; turns out, Butteraugli is only smart at high quality levels. And they\u2019ve been forthright about the fact that their tool is ripe<\/a> for optimization<\/a>. But as it stands, their encoder burns through vast quantities of memory and processing power in order to output JPEGs with precise, and rather high, levels of Butteraugli-calculated \u201cquality.\u201d<\/p>\n
What does this actually look like, in practice?<\/p>\n
Sfumato? q_auto<\/code>!<\/h2>\n
Here\u2019s a comparison between three versions of the Mona Lisa<\/a>: a lossless original, and JPEGs encoded by both Guetzli and q_auto<\/code>.<\/p>\n
My first impressions: both the Guetzli and the q_auto<\/code> look quite good. Up close, both seem slightly \u201cfuzzier\u201d than the original. But neither really seems much better or worse than the other \u2013 and the q_auto<\/code> comes in 19% lighter, by bytes.<\/p>\n
Breaking out my pixel-peepers<\/a>, I could start to see some more interesting differences. In Mona\u2019s face, q_auto<\/code> appears smoother; Guetzli, blockier.<\/p>\n