JyrkiAlakuijala

13 CVEs (6 CVEs on decoding) over five years is a moderate or good track record. Legacy format libraries like libjpeg, libpng, or libtiff have historically accumulated dozens or hundreds of CVEs even if they were built several years before the CVE process was started.

libjxl's vulnerability rate is low, but it still reflects the growing pains of a modern high-quality C/C++ parsing library.

With Rust things can be safer: For jxl-oxide there is one CVE. libjxl-rs does not yet have filed CVEs.

that article does not seem specify which bit rates/quality targets were used for analysis, and uses a 1980s scanned photography film scan corpus for the claims ... let's use digital photography test corpora nowadays!

JPEG XL has been designed for keeping the image intact at the lowest possible bits per pixel (BPP), usually around 1 to 1.6 BPP.

AV1 was designed to deliver a pretty good new frame with as low as possible budget, and further video frames could bring the missing detail later. AVIF/AV1 has much more aggressive filtering and more features that are well suited for low bit budgets -- but also is missing features that are needed to get things right at higher quality.

JPEG XL can control filter strenght at 8x8 pixel resolution, whereas in AVIF filter strenght is constant over a 64x64 block.

Similarly, adaptive quantization is more fine grained in JPEG XL.

Finally, adaptive quantization automatically modulates the filter strength in JPEG XL (but not in AVIF), so the same data does not need to be sent twice for this purpose.

All of these three differences are visible in bit budgets only in the higher quality images.

JPEG XL decoder complexity is propaganda.

JPEG XL decoder is smaller in kloc than zlib+libpng. About 35 kloc vs 20+20 kloc.

Twelve years after the effort began, JPEG XL is fully coming into its own. We started by advancing psychovisual modeling with Butteraugli, inventing the XYB colorspace, and developing Guetzli and Brunsli. This groundwork led to PIK, and during the JPEG XL competition, I proposed a two-platform approach to the committee that successfully fused PIK and FUIF into the final standard.

Following successful adoption in professional photography (Digital Negative etc.), documents (PDF/EPUB), and medical imaging (DICOM), we are now completing full Web compatibility.

Our next frontier is bringing native JPEG XL support to cameras, including smartphone cameras.

Depends on the user. Some users are more sensitive for flashing images. Some users have very slow or unreliable network connection. Some sites have bigger images. Some sites (such as ecommerce) have higher quality and resolution needs.

Some users have uncorrected astigmatism. In the general population, the average uncorrected astigmatism typically falls between 0.50 and 0.75 diopters (D), and ~15 % more than 1.0. The high astigmatism people will see images blurred in any case and don't benefit from the fine structural detail JPEG XL can give. People with glasses and the lucky ones with low astigmatism will see the details clearly.

Sometimes passionate ends of different quality of vision seem to have a discussion on what makes sense as the web quality, with one emphasizing quality 40 being more than enough and another requesting a quality of 95.

The same kind of individualism exist also in temporal cognition and perception.

I made that AI rendering and consider it demonstrates the conceptual discussions we had likely better than what an actual whiteboard drawing would look like. An actual whiteboard drawing from our day to day work would be very confusing without a lot of context and discussion. I have to admit that whiteboard drawings were somewhat rare in our real JPEG XL development, but it has been an intensively collaborative effort.

Parent comment says I should not be known and my picture should not be on the blog post. I just want to disagree with that. In my opinion JPEG XL is a notable success and it is also ok to celebrate us, its makers.

No it would not, qoi falls behind even my 2011 WebP lossless design.

Also, it is not a competition for the shortest specification. If it was, still good. Jpeg xl spec is about half the size of the original jpeg spec.

I wrote it, with some help from Gemini as my own English is clumsy and expensive to correct manually, and created the "photo" and the "chart". I am to blame. I thought the story of a 10+ year running OSS project with intermediate milestones would be fascinating for people.

Thank you.

Jpegli is still a hidden gem. People don't yet understand how great it is.

We (Google) built JPEG XL (together with Cloudinary). The main photography mode and the JPEG compatibility mode is from Google.

Chrome decided not to be an early adopter for good reasons that they have publicly documented, but that did nothing to JPEG XL. Particularly, it did not kill JPEG XL. Others, DNG, DICOM, PDF, EPUB, iOS, Safari, etc. integrated it early regardless.

No, it is normal. Similarly Jon's blog post does not name any of us by name.

Two reasons: The people in the pic look more or less like our real ourselves. The synthesized photo shows the process of discussing highly conceptual approaches, which was our everyday for 10 years or so.

This was not a factor. It was either staging the photograph or AI. Photographing inside the office can be a complex process with seeking appropriate permissions, and I didn't have an alternative space to do the photography. AI felt like an easier solution.

True, no one can understand my whiteboard drawings the next day, not even I.

This discussion happened in a chat window in reality, but is based on a real discussion between me and Luca, leading to reversing the order of "ac strategy" from splitting to joining.

I spent 10+ years in building JPEG XL and I'm proud of the result. It wasn't always easy times. It is not so bad people can see what I look like and take a peek what the process was to get there.

This article is not about the entropy codes and predictors, memory bandwidth and decision trees, but about the long horizon planning in corporate-driven OSS efforts and being connected to both community and cross-industry.

I designed the lossless format and its initial encoder. Zoltán Szabadka wrote the initial lossless decoder.

On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for better quality, inventing workarounds for the YUV420 sampling quality issues), but did not change the format's image-related aspects that On2 Technologies had come up with for VP8 video use.

In the end stage of lossless productization (around February 2012) Skal had minor impact on the lossless format:

1. He asked it to have the same size limitations (16383x16383 pixels) like lossy.

2. He wanted to remove some expressivity for easier time for hardware implementations, perhaps a 0.5 % hit on density.

Skal also took care of integrating the lossless format into the lossy as an alpha layer.

Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality.

JPEG XL is not that massive.

JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.

A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.

A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.

A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.

The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.

Thank you!

I designed WebP lossless alone. The rest of the WebP folks added a RIFF header and an artificial size limitation (16383x16383) to match with the size limitation of lossy WebP.

In JPEG XL I believe I had more influence on the lossy ("VarDCT") format than anyone else, but stayed relatively far from the lossless part (except the delta palette, two predictors, 2d lz-codes, and a few other smaller things). I believe Jon and Luca had most influence there.

Not really. FLIF is too slow to decode, about 20x slower than WebP lossless. JPEG XL modular mode uses a similar static context modeling with WebP lossless and Brotli and likely LZHAM where all the entropy codes are generated at decoding time. Also JPEG XL forces tiled coding, making multi-threaded decoding a possibility.

When I built WebP lossless format I kept testing design decisions against PNG. The average gain against my Internet PNG test corpus was 42 % and 26.5 % if I optimized the PNGs with pngcrush and pngout (kzip). I had not yet come up with ZopfliPNG ideas, those were backports from some WebP lossless ideas into gzip and PNG.

the article includes test code and encoder code, that is not the way how we compute the decoder size

the decoder is something around 30 kloc

This is some strange misinformation.

The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.

It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.

JPEG XL supports UltraHDR.

JPEG XL's normal HDR capabilities were not harmed in the process when UltraHDR was added.

It was added for reaching parity with JPEG1 and HEIF/AVIF for the needs of UltraHDR developers and believers.

Brotli decompresses 3-5x faster than LZMA2 and is within 0.6 % of the compression density, and much better for short documents.

ZStandard decompresses ~2x faster than Brotli but is 5 % less dense in compression density, and even less dense for short documents or documents where the static dictionary can be used.

Brotli is not slow to decompress -- generally a little faster then deflate through zlib.

Last time I measured, Brotli had ~2x smaller binary size than zstd (dec+enc).

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

Zstd decompresses faster, perhaps 2x faster, but Brotli is fast enough. Often a little faster than gzip/deflate.

Brotli can compress more because of context modeling, about 5% more without the static dictionary and even more with it. Brotli works better with very short data.

Brotli is a bit more streamable than zstd, i.e., hides less data during transfer.

Zstd has better encoder implementations, but basically there is no technical difference in the demands of the format on the encoding algorithms. Compression could be equally fast, Zstd just saw more love and specialization for encoding. As a result, Zstd libs are 2x heavier than Brotli.

The original JPEG XL requirements were relational colors, where colors are an issue external to the codec. I was able to sufficiently convince the rest of the jpeg committee that we can achieve similar interoperability with absolute color, and particularly my xyb color space, and the absolute color storage giving us more opportunity to psychovisual optimization. Also, I was behind not having 8, 10, 12 bit modes, but just a single mode, and always yuv444 — to simplify operation and creating less confusion and less hard additional quality boundaries. Some of this "beauty" such as no yuv420 we needed to backtrack from for adding the lossless jpeg1 recompression support.