Jpegli: A new JPEG coding library

Original Article ↗ Hacker News Discussion ↗

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.