Jpegli: A new JPEG coding library

Original Article ↗ Hacker News Discussion ↗

Google’s new Jpegli library aims to produce smaller, higher-quality JPEG images while remaining fully compatible with existing decoders, and early tests show it dramatically outperforms the older Guetzli encoder in speed with comparable or better visual quality. Commenters are intrigued by its ability to squeeze ~10.5 bits of effective precision out of the traditional 8‑bit JPEG format, debate its competitiveness against formats like WebP, AVIF, and JPEG XL, and note that it can often be a drop-in replacement for libjpeg-turbo or MozJPEG. The release also revives broader arguments about Google’s codec strategy, perceived reluctance to back JPEG XL in Chrome, and the trade-offs between introducing new formats versus pushing legacy ones further.

WASM and tooling

  • Multiple people ask about a WebAssembly build; some already use MozJPEG via WASM and want to experiment with Jpegli.
  • Suggestions include a demo site and a fork of Squoosh to make trying it easy.

Performance and quality vs other JPEG encoders

  • Several users compare Jpegli to Guetzli: claims of roughly ~1000x faster encoding with similar or slightly lower quality at very high settings, and better behavior at medium qualities.
  • One detailed anecdote: Jpegli produced a similar-size file in milliseconds vs Guetzli’s many seconds; initial impression that Guetzli handled gradients better was later retracted after closer inspection.
  • Jpegli is reported to degrade “gracefully” down to lower quality levels (e.g., 60–80), unlike Guetzli which restricts quality.
  • Mixed reports vs MozJPEG/libjpeg-turbo: some tests and linked studies say Jpegli is better across medium–high qualities; one user reports worse results at very low bitrates, which others dispute as possibly outdated.

“10+ bits” and HDR behavior

  • Jpegli claims ~10.5 bits of effective precision while remaining a standard 8-bit JPEG stream.
  • Discussion explains this comes from using 12-bit DCT coefficients, high-precision (floating-point) internal math, and dithering; extra precision mainly helps avoid banding in smooth gradients.
  • Existing 8‑bit decoders can display such files, but full benefit needs Jpegli’s extended API or a decoder aware of higher-precision output.
  • This is unrelated to Ultra HDR / gain-map JPEGs, though Jpegli could hypothetically be used inside those.

Compatibility and deployment

  • Encoded files are standard JPEG and decode in existing software; Jpegli as a decoder can additionally output higher bit depth and perform dithering.
  • Package availability is noted for some Linux distros and a GUI converter; users expect integration into popular optimization tools.

Language choice and safety (C++ vs Wuffs/Rust)

  • Some question why it’s written in C++ instead of Wuffs or Rust.
  • Replies say: Jpegli builds on existing C++/C ecosystems, aims for easy drop‑in adoption, and is still active research where Wuffs’ strictness and lack of syscalls are inconvenient.
  • Wuffs is described as focused on safe, high-performance decoding; sophisticated encoders are currently a weaker fit.

Relation to JPEG XL, WebP, and AVIF

  • Many comments tie Jpegli to the broader controversy around Chrome dropping JPEG XL while promoting WebP/AVIF.
  • Some see Jpegli as an answer to Chrome’s stated preference for “optimizing existing formats” instead of adding new ones.
  • Opinions diverge:
    • Pro‑Jpegli: It gives WebP-like or better savings at medium/high quality with full JPEG compatibility; may make WebP less compelling, and even challenge AVIF for some high-res, high‑quality photos.
    • Pro‑JPEG XL: Jpegli is welcome but cannot replace JPEG XL’s broader feature set (native HDR, lossless, better generational robustness, streaming/progressive decoding). Some still want JPEG XL as the long‑term successor.
    • Skeptical view: Google’s format strategy (WebP/AVIF vs JPEG XL) is seen by some as political or conflicted; others argue JPEG XL’s implementation and process weren’t mature enough for browsers.

Use cases and limitations

  • Jpegli seems strongest for medium-to-high quality photography and backward-compatible web delivery.
  • At very low quality (thumbnails, high-density grids), at least one user finds MozJPEG/libjpeg‑turbo preferable; others suggest resizing strategies because JPEG’s fixed block size is a poor fit for tiny, highly compressed images.

Image quality evaluation

  • The project uses crowdsourced pairwise comparisons and Elo-style ranking to compare encoders at matched bitrates.
  • Some question whether pairwise preference (which can favor more saturated images) is ideal; clarification is added that raters also see the original for reference.
  • There is interest in deeper analysis of when and why one encoder wins (artifacts, color, frequency content), but that’s not fully explored in the thread.

Naming and regional flavor

  • The “‑li” suffix is recognized as a Swiss German diminutive (“small JPEG”), matching other Google compression projects with similar names.