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:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

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

ROCK 5 ITX Rockchip RK3588 mini-ITX motherboard

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

  1. 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.

    1. You’re right, but my initial idea was to compare the compression to libjpeg-turbo, but I then found out the test program for the latter does not support PNG at all. So I just quickly tested the encoding and decoding program to show people how to install the programs and make sure they work.

  2. 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.

    1. The source file was a screenshot with few colors and text, so not exactly the ideal candidate to showcase libjpegli as explained by Willy above.

  3. 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 get “feeling
    the problem”. Results for jpegli are of course in lossy section:
    https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#what_about_lossy_
    BTW JPEG XL can compress loseless and lossy.

    4. It is nice to hear that we (as people) can encode with better quality with border of JPEG bitstream, but we already have successor – JPEG XL. JPEG XL is great and universal image format.

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

  5. 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

    1. 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).

  6. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip RK3588S SBC with 8K, WiFI 6, 4G LTE, NVME SSD, HDMI 2.1...
Boardcon Rockchip RK3588S SBC with 8K, WiFI 6, 4G LTE, NVME SSD, HDMI 2.1...