Google’s Jpegli open-source library can compress high quality images 35% more than traditional JPEG codecs

Google has released the Jpegli open-source library for advanced JPEG coding that maintains backward compatibility while delivering an up to 35% compression ratio improvement at high-quality compression settings.

Google Research has been working on improving the compression of data (Brotli), audio (e.g. Lyra V2), and images with a project such as WebP for many years in order to speed up the web and make it consume less bandwidth for dollar savings and lower carbon emissions.  Jpegli is their latest project and aims to improve the compression ratio of legacy JPEG files on systems were modern compression such as WebP may not be available or desirable.

Jpegli ELO score vs other JPEG libraries
Jpegli ELO score vs libjpeg-turbo and MozJPEG at several bitrates.

Jpegli highlights:

  • Support both an encoder and decoder complying with the original JPEG standard (8-bit) and offering API/ABI compatibility with libjpeg-turbo and MozJPEG.
  • Focus on high-quality results with up to 35% better compression ratio.
  • Just as fast as libjpeg-turbo and MozJPEG.
  • Support for 10+ bits coding. Google explains traditional JPEG coding solutions offer only 8-bit per component dynamics causing visible banding artifacts in slow gradients, but Jpegli’s 10+ bits coding works around this while remaining compatible with 8-bit viewers. Benefiting from the extra bits requires code changes available through an API.

Jpegli works by using adaptive quantization heuristics from the JPEG XL reference implementation and an improved quantization matrix selection to respectively reduce noise and improve image quality AND optimize (the data) for a mix of psychovisual quality metrics. Google’s open-source blog has more details about the internals of the library.

Jpegli JPEG encoder and decoder implementation is part of the JPEG XL image format reference implementation  (libjxl) and you’ll find the source code on GitHub. Eventually, it might be integrated into your favorite libraries and programs, and you’ll be able to install JPEG XL’s Jpegli support from the libjxl-tools package in your preferred Linux distribution. But in the meantime, we can use the tools/cjpegli and tools/djpegli tools by building libjxl from source (tested in Ubuntu 22.04):


Once the build is complete, we can check the usage for the decompression and compression utilities:


I used a PNG screenshot for testing compression first:


It did the job and I could open the resulting file with the GNOME image viewer with very small differences against the PNG file in terms of quality after zooming on specific zones (text), but a smaller file size:


The decompress command works about the same way:


The resulting PNG file is much bigger than the original, but that’s normal due to the artifact created by the JPEG compression:


Anyway, it’s easy to try with various image files and compare the results against jpeg-turbo, MozJPEG, or graphical tools like GIMP making sure to use the same compression settings.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
9 Comments
oldest
newest
Willy
6 months ago

IMHO you should have compared a JPG before and after. PNG is lossless and based on LZ compression, so it cannot be compared to JPG. Typically PNG will work great with screenshots with large uniform areas where JPG causes ugly artefacts, while PNG will work poorly with an outdoor photo while JPG will excel. Any photo of your yearly hardware giveway could be used for example, and compared before/after. And they’re usually great because if the input quality is good, there are often high details such as board names etc to compare input and output.

Anon
Anon
6 months ago

Good demonstration of the level of artifacts created by the new jpeg codec for very little size advantage. It’s almost like it’s an announcement by Google to let us all know how clever they are, diverting attention from their surveillance of everyone on or off the internet for their profit.

susr
susr
6 months ago

My two cents for article. 1. FUIF is not Google, Google PIK + Cloudinary FUIF = JPEG XL, more at: https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-going 2. I would like to stress that sentence: “Google Research has been working on improving the compression of data (…) for many years in order to speed up the web and make it consume less bandwidth for dollar savings and lower carbon emissions” is true if we talk about Google Research only. Removal of JPEG XL from Chromium shows that Google as coorporation “thinks” differently, more at: https://cloudinary.com/blog/the-case-for-jpeg-xl 3. Proper format comparison is complicated thing. Please read https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front to… Read more »

willmore
willmore
6 months ago

In your build instructions you skipped the mkdir build; cd build line before the first cmake invocation.

krish
krish
6 months ago

I followed all the steps, but getting following issue:

$debian:~/libjxl$ time tools/cjpegli ElectronicsSide686x686.png \ ElectronicsSide686x686.jpg

Failed to decode input image ElectronicsSide686x686.png

real  0m0.006s
user  0m0.000s
sys   0m0.006s

susr
susr
5 months ago

If ElectronicsSide686x686.png is valid PNG file, most propably your cjpegli does not have png support compiled due to lack of libpng-dev in your system. More in BUILDING.md file (around line 48).

Jason Peterson
Jason Peterson
4 months ago

This codec offers a middle ground between full and subsampled chroma. It provides separate tables for the red and blue channels where the highest coefficients are significantly quantized at high quality of around 97. I still can’t see noticeable color smearing. The high bitdepth works on shallow gradients, but needs a Li decoder to recover the high precision data. For normal decoders strong dithering provides better quality. Otherwise normal decoders will show more banding. For maximum quality, decode with –bitdepth=16 and dither. The speed of JpegLI is good, unlike some optimizers that take minutes to finish.

Khadas VIM4 SBC