Google’s new JPEG image encoder offers higher quality and saves on size and bandwidth

We humans are visual creatures, and while video is the predominant choice for information consumption online these days, making up over 80% of all the online traffic, images have and will continue to play a major part in the digital experience. Whether we like to think about it or not, all of the data bandwidth we consume has a cost and titans of industry like Google have a vested interest to optimize said cost. Well, for better or worse, the search giant’s last effort in the image format space – WebP didn’t exactly go so well and failed to come close to its goal of replacing JPG, PNG and GIF.

So, Google changed its approach and decided to make JPEG better instead of fighting against its ubiquitous status. Enter jpegli. It is a JPEG coding library that contains both an encoder and a decoder. Probably the most important bit is that both the encoder and decoder comply with “the original JPEG standard and its most conventional 8-bit formalism”. In simpler terms this means that the images encoded using jpegli are drop-in compatible with existing decoders like your browser or image viewer of choice.

Now, we won’t pretend like we know exactly what kind of “black magic” Google is using in jpegli. According to the press release, it “uses adaptive quantization to reduce noise and improve image quality. This is done by spatially modulating the dead zone in quantization based on psychovisual modeling.”.

However, some of jpegli’s outlined benefits are much easier to grasp. Such as the fact that it compressed images around 35% more than traditional JPEG codecs while preserving their visual quality. That alone is a huge win for online bandwidth. If nothing else, just think of how much space Google themselves would save in Google Photos by reencoding user content. Also, jpegli apparently performs “more precise and psychovisually effective computations, ” making images “look clearer and have fewer observable artifacts.” It can also encode images with 10+ bits per component compared to the 8 bits of traditional JPEG coding solutions, which happens in the original 8-bit formalism without breaking compatibility with traditional 8-bit viewers while reducing “visible banding artifacts in slow gradients”. And last but not least, jpegli is apparently comparable in speed to other coding libraries, so it won’t cost any additional computational resources or show processes down.

A higher ELO score indicates a better aggregate performance