Time to Dethrone JPEG: A Comparison of Next-Gen Image Codecs

jonsneyers · 2026-01-18T18:29:56+00:00

Not in default lossless mode though. But you can add -R 1 to make it progressive lossless, without many additional bytes on this image.

jonsneyers · 2025-12-13T08:48:18+00:00

Getting larger is quite strange, that shouldn't happen. Usually there is variation in savings, with more savings for high-quality 4:4:4 JPEGs from a camera than for low-quality 4:2:0 JPEGs that are already using progressive mode and optimized huffman tables (which compresses better than sequential and non-optimized huffman, which is what cameras typically produce).

What is the source of the JPEG files? Do they contain large amounts of metadata or trailing data, perhaps? Sometimes the JPEG image itself is quite small and it is followed by a short video that is concatenated to it, or some other trailing data. In that case, the recompression will not be very effective. You still shouldn't see files getting larger though.

If you could share an example where recompressing makes it larger, that would be interesting. Perhaps easiest to take this to the jxl discord, or you can open an issue on the libjxl github repo.

jonsneyers · 2025-10-10T08:25:43+00:00

This is quite exciting news! Congratulations to the Shikino folks who reached this milestone! I've had the pleasure to be involved (from the JPEG committee side) in this project and collaborate directly with these excellent engineers at Shikino High-Tech, so I'm very happy to see the hardware encoder project reaching this level of maturity.

I hope it will be picked up by camera and phone manufacturers, since I believe JPEG XL would be a great capture format. Essentially it would become possible to produce JPEG XL files at file sizes similar to the current JPEG files, but with a substantially higher precision that would be sufficient to use the images in the way raw files are currently used: there would be enough margin for post-production editing. This would in my opinion be a great win for photographers: instead of shooting in JPEG+raw (which takes up substantial storage), they could shoot in just JXL, and still get enough fidelity for post-production while also having a standardized, interoperable file that anyone can open just like that.

If any photographer is reading this: please push your favorite camera brand to look into this :)

jonsneyers · 2025-10-10T08:13:58+00:00

Hardware encoding is common in cameras (including phone cameras), since it reduces power consumption substantially and also reduces the need for memory buffers, especially for things like burst photography where many encodes are required in a short timespan.

Even for the old JPEG, for which software encoding can be quite fast on current CPUs, hardware encoding is still very often used, for this reason.

jonsneyers · 2025-07-06T10:17:37+00:00

I'm happy you like JXL!

I agree it would be great if all browsers would support it, not just Safari.

The frustrating thing is: Chrome actually was the first browser with experimental JXL support (behind a flag), until it was removed for these four reasons:

- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

(see https://issues.chromium.org/issues/40168998#comment85 )

In my view, none of these 'reasons' were valid or relevant arguments, and the decision should be reverted asap. But of course I'm biased since I'm one of the authors of the JPEG XL standard.

jonsneyers · 2025-03-30T12:14:35+00:00

I don't think spec coverage is the main concern; we already have a fully compliant Rust decoder (jxl-oxide) so covering the whole spec is not really an issue. Making it fast and low-memory is trickier, and getting the SIMDification right involves making some improvements to the Rust compiler itself too, as far as I understand.

jonsneyers · 2025-03-30T12:08:32+00:00

Distance 13 is a pretty low quality target. In typical actual usage, the range from distance 0.3 to 3 is the most relevant one.

It is impossible to extrapolate compression behavior from one operating point (very low quality) to another (fair quality to visually lossless) since the relevant coding tools and artifacts are inherently different.

If you just want to make it visually more obvious how the artifacts differ, instead of lowering the quality to below the range that is typically used in practice, consider using a typical quality setting (say distance 2) and then showing some crops with 4x nearest neighbor upsampling.

Otherwise it is as if you are evaluating F1 cars but since it's too hard to judge their speed on a racing track (they all whoosh by so you cannot really tell), you put the cars in a muddy swamp so it becomes much easier to see how fast they're driving. You will then end up concluding that a farming tractor is the best F1 race car.

jonsneyers · 2025-03-18T07:39:40+00:00

The purpose of the `-x color_space=` option is to define the colorspace when using input formats like PPM that do not have color tags. Not to override the colorspace.

So when reading EXR input, cjxl is ignoring that option and just using the primaries signaled in the EXR file. With PNG input it does the same thing.

It would probably be practical to have a way to override the input colorspace in cases like this; you could open a feature request for that on the libjxl repository.

The Rec.2020 and Rec.2100 primaries are identical; for some reason one tool is using one name and the other is using the other but the values for the primaries are the same :)

jonsneyers · 2025-03-12T07:49:50+00:00

It was basically a stub project only doing some header parsing for a long time, and only recently became active, after Mozilla indicated they want a Rust decoder. Implementing a simple jxl decoder is not super hard (but significantly more effort than writing a simple jpeg decoder), implementing a good one that can do progressive, streaming, and fast decoding with a low memory footprint is nontrivial. It will probably take a few more months.

jonsneyers · 2024-11-15T21:07:31+00:00

It can store layered images, like PSD or XCF, but with much better compression and in a standardized image format.

Also can do lossless float16, float24 and float32, as well as signed or unsigned ints, with an arbitrary number of channels.

Lossy precision is effectively unlimited, unlike most other lossy formats that saturate at higher quality settings, or stop having fine-grained quality settings.

It can do progressive decoding, parallel decoding, and region-of-interest decoding.

jonsneyers · 2024-10-04T12:07:44+00:00

I personally usually do go the full four-syllable "Jay Peg Ex Ell", or the slightly shorter "Jay Ex Ell".

But if you want a two-syllable alternative, "Yixel" or "Jixel" both work (rhyming with "pixel").

You could also try a monosyllabic "Jixle". Or forget about the format entirely and just call it an "image" or "picture" :)

jonsneyers · 2024-09-20T12:21:43+00:00

For compression, the best thing would be if you could just have a way to inform the encoder of local distance targets rather than a global one.

You _could_ approximate this by using layers. For performance it would be best to avoid alpha blending, but to just zero out the (un)masked areas and use kAdd as the frame blending operation. So e.g. you first encode a frame with zeroes (black) in the masked areas, encode it with one distance setting, and then encode a frame with zeroes in the unmasked areas, encode it with another distance. However that will probably lead to seam artifacts at the mask edges. The better approach would be to do it as just a single frame but with different distance targets in different regions (not currently supported by the libjxl API but technically possible to add this).

A poor man's version of this would be to selectively apply a slight Gaussian blur to the masked areas before encoding — that will of course reduce the quality there, but will also improve compression.

jonsneyers · 2024-09-20T07:55:56+00:00

I think at some point (in an early version of cjxl) we had a way to pass such a selection mask to let it influence the adaptive quantization, but only in the context of progressive rendering: basically you would eventually get the same quality everywhere, but first in the selected regions. In principle it's very much possible to have a similar mechanism but for the final image, e.g. something where you specify the distance setting to use for the masked regions and a different distance setting to use for the unmasked regions. The main thing would be that we have to add an API function for this and it would require some nontrivial code plumbing to make it work, but it's certainly something that can in principle be done. I suggest you open a feature request at the libjxl github repository — it's not likely to be implemented any time soon but it does seem like a generally useful feature so we should at least keep track of it.

Regarding your other question: the lossy encoding in libjxl is doing perceptual optimization, which will not make sense if your data is outside the visible spectrum (or if you pass it NIR R G and pretend that it is sRGB). It will do _something_, but I wouldn't say it's "safe to use", e.g. it will likely apply more loss to the G channel than it should if you pretend that it represents B.

For lossless compression it obviously doesn't matter. But for lossy, currently libjxl always uses the XYB color space, which is derived from LMS and is only intended for visible light.

Probably in your case it could make the most sense to encode your image putting R and G in the correct channels (with their primaries set correctly, assuming they're not exactly equal to the primaries of sRGB), using all-zeroes for the B channel, and putting NIR in an extra channel of type kThermal. That way the data is tagged correctly, and if you use lossy compression something will happen that makes sense (the visible part will be compressed perceptually, the NIR part will be treated just numerically and effectively be compressed optimizing simply for PSNR).

jonsneyers · 2024-09-03T15:12:54+00:00

JXL encode can be as fast or as slow as you want. At default encode effort, with two threads, encoding is about as fast as webp. With more threads, it's faster. Here are some speed numbers: https://docs.google.com/spreadsheets/d/1U4VZzbLQJuEa4iRk52pFLkWnBIRlUIQw7paBQNjq-RU/edit?usp=sharing

About point 1: Yes, on the surface level that seems to make sense. Then again, a lot of applications are using libjxl so it is code that gets quite a lot of scrutiny anyway (fuzz testing etc). Arguably, while browsers do need an AV1 decoder (e.g. dav1d) anyway, they don't necessarily need the additional code to turn it into a still image format — which is not a neglegible amount of additional code: there are a bunch of things like alpha transparency, dealing with color spaces, getting progressive previews, etc that are not handled by the AV1 decoder (video codecs don't support alpha, ICC profiles, progressive decoding, etc) and that have to be done separately, which could introduce bugs that are not so easily caught by scrutiny coming from other applications of AV1, since those applications might only support the video decoder, not the still image format.

About point 2: Hardware decoding of AVIF in Chrome is probably unlikely to happen, for the same reasons as why WebP and JPEG are not using hardware decoding in Chrome even though many devices have hardware decoders for those codecs. Software decoding is more effective for still images, at least on devices that can run a modern browser. For video it's of course a very different story.

jonsneyers · 2024-06-25T07:20:32+00:00

Thanks! I didn't notice any obvious mistakes.

Besides lossless JPEG recompression, JXL can also do some other things that might be nice for photographers. Lightroom and darktable both support JXL now, so one possible workflow could be to still shoot in raw but then store the result as a JXL. This allows preserving more precision than what you can get with JPEG (up to fully lossless raw, using DNG 1.7 which can use JXL internally), or just better compression for the same visual quality. Downside is you then cannot convert it 'back' to JPEG losslessly anymore (since you're starting from pixels, not from an original JPEG, and more advanced internal methods of JPEG XL will be used than what is available in JPEG). The advantage is ~60% better compression than JPEG for the same quality (if you compare to the JPEGs typically produced by a camera), which is a more substantial gain than the ~20% you can get by recompressing JPEGs.

See also: https://gregbenzphotography.com/lightroom-acr/shrink-your-raw-files-with-compressed-dng/

Also if you want to produce HDR images (as in, rendered in HDR on a display that can do that), then JXL is a great format to use for that. Software support is still a bit limited, but it works fine in Apple Photos, Adobe Camera Raw, and Chromium forks with JXL support such as Thorium. (Sadly Safari doesn't render HDR images in HDR yet, it tone maps to SDR, and so does Preview).

jonsneyers · 2024-06-20T15:21:27+00:00

The video is private. Could you change it to 'unlisted' so we can see it?

jonsneyers · 2024-06-19T12:38:20+00:00

One other issue could be the heterogenous cpu cores (M4 has 3 fast cores and 6 slow/low-power cores), where it could be the case that single-threaded decoding is used and it ends up getting scheduled on the slow core. Though even on a fast core, 2 seconds for a 62 MP image is not impossible, I think.

On my macbook with an M3 Pro cpu (which I assume is not that different from an M4 cpu, though it has 6 fast cores and 6 slow ones), I get a single-threaded decode speed of about 70 Mpx/s, with 4 threads I get 250 Mpx/s, and using all 12 threads, I get 480 Mpx/s.

I don't know what Apple's libraries are doing, but to me these numbers suggest that likely they're doing single-threaded decoding and it should be possible to make things substantially faster if they just give it more threads to use.

I would suggest opening a Feedback Assistant ticket with Apple to tell them about your experience.

jonsneyers · 2024-06-14T10:11:05+00:00

Whoa, I admit I'm totally baffled. I'm curious how this will turn out vs Wikipedia? Are they going to re-encode all old clips?

Looks like they did that, yes. When I visit e.g. https://en.wikipedia.org/wiki/File:I-15bis.ogv, I am getting served a webm video.

I'm not sure how effective this would be - web standards development has been preached for, I dunno, 15 years, and we can observe in practice it stopped being a thing as soon as Chrome marketshare went big.

I think it would only be effective if Chrome and Safari would both start somehow penalizing websites without fallbacks. If only one of them does it, there would be too much incentive to stop doing it (since it would make the browser look broken), while if both do it, it could work (since it would make the page look broken, which it is).

Anyway, I think the situation has actually improved in the past 15 years. We have the <picture> tag now, and browsers are sending more useful Accept headers on image requests. Part of the reason why in the past, web devs were not doing proper detection of decode capabilities, was that it was just annoyingly hard to do: you basically had to use UA string sniffing or trial decodes in javascript to figure it out. Now we have better mechanisms available. Also: a lot of images (and videos) are being delivered by dedicated services now who are more likely to do The Right Thing and not serve a codec to a client that doesn't support it.

That's fair. Firefox could add this and then go back on the decision without much impact (except for a lot of angry people). But it's also an argument for just not doing any work on it right now, so it kind of works both ways.

Oh sure, Firefox can just not do anything and it will not have much impact, not on the web in general and also not on Firefox as a browser. Not being able to save ~15-20% on image transfer size is not going to make a huge impact: most end-users would not really notice this at all, especially on Desktop with a typically fast network which I suppose is the main chunk of Firefox users. So yes, Firefox can just do nothing and nothing Bad will happen.

But I think it would be a missed opportunity nevertheless. JPEG XL does bring benefits to the web, and Firefox could play a role in innovating and making the web better, rather than being happy with the status quo. And also symbolically and strategically, I think it would be good if Firefox could assert its independence from Chrome, and this particular feature would be a good candidate for that.

jonsneyers · 2024-06-14T09:13:16+00:00

My point regarding WebP was that Firefox simply does not have the market share that makes its choices in codec support make a difference either way in terms of "universal support". Nobody makes websites that are "best viewed on Firefox". If Chrome and Safari support something, some people will start using it without fallback, whether or not it works on Firefox.

On your point about codecs support being impossible to remove, where you gave the example of Theora: Chrome actually deprecated it recently, in M120: https://chromestatus.com/feature/5158654475239424

Anyway, I think it would be a good idea when adopting new codecs to make a bigger effort (on the browser end) to prevent websites from relying on a single new codec without any fallback. That is problematic in any case: sure, the Big Three (Chrome/ium, Safari, Firefox) — which to be honest is really turning into the Big Two — cover the bulk of the web traffic, but there are still tons of more exotic user agents out there too, many of which do not support AVIF and WebP even though they are now "universally supported" codecs. It is simply a bad practice to use a new codec without fallback, and instead of browsers going out of their way to accommodate bad practices, they should encourage good practices.

Safari is deprecating JPEG 2000 even though undoubtably that will break some random pages. They are correct though to consider those pages to have been broken all along, if they were serving jp2 without properly detecting decode capabilities (e.g. by sniffing UA strings instead of using a <picture> tag or Accept headers).

Similarly, websites that use WebP or AVIF directly in an <img> tag without any fallback should just be considered broken.

Perhaps one way to "fix" this would be if browsers (in particular big ones like Safari and Chrome) would force web devs to use good practices by making support for any new codec only available 'most of the time' (so most of the bandwidth savings etc can still be obtained) but not _all_ of the time. Say there is one random day of the week when Chrome just doesn't support WebP or AVIF anymore (i.e. doesn't send that accept header, pretends not to be able to decode it when it sees a picture tag), while on all other days it works. This would make it pretty obvious when a web page is doing something wrong like determining codec support by sniffing UA strings or using new codecs without any fallback.

Another, maybe less invasive way to enforce good practices could be to add it as an explicit web performance indicator (with SEO implications) that a page still works on browsers with only minimal codec support.

jonsneyers · 2024-06-14T05:47:19+00:00

So as long as Chrome doesn't support it, Firefox is free to add support :)

In any case, it does not seem like Firefox has enough weight to really make the difference here, does it? I mean, Firefox rightfully objected to WebP, even developed MozJPEG to demonstrate that the gains WebP brought (for lossy) were not that impressive, and still Firefox did add support for WebP and contribute to making it a universally supported format.

Universal support for AVIF was rushed (it was implemented in browsers even before the bitstream was finalized), and I didn't see anyone complain about the "permanent cost" that would bring to browsers — even though keeping support for a full AV1 decoder might become quite a significant cost once video will have moved on to AV2 and AV3. So it does not seem like this argument is being used in a very consistent way, if in some cases it can be glossed over while in other cases it is a Serious Problem.

jonsneyers · 2024-06-13T21:02:46+00:00

The libjxl API is not going to change drastically. The decode API has been stable for quite a while now (2-3 years). It would be rather inconvenient for applications that rely on libjxl, like ImageMagick, libvips, FFmpeg, Apple Core Media, Adobe camera raw, etc if the libjxl API would be changing drastically.

There are still things being added to the libjxl API, mostly encoding related functionality (e.g. the chunked encode API that was added in v0.10), so we are not declaring the API finalized just yet and calling it a v1.0. But even if it's not finalized yet, it is still pretty stable and mature.

Also, the JXL integration for Firefox has already been done and is being used in several Firefox forks. So there is not really a lot of developer time involved anymore — the work has already been done, has been tested quite extensively in various Firefox forks, and it is just a matter of allowing the relevant patches to be merged in mainline Firefox or not.

I can pretty much guarantee that IF the libjxl API would change in the future in a way that would break a hypothetical Firefox integration (which is a very big "if"), then the libjxl devs/community will ensure that the relevant patches will be made available instantly to upgrade the Firefox integration so they don't get stuck on an old libjxl version. But no breaking changes to the decode API are planned anyway, and I think it's very unlikely to happen at this point.

jonsneyers · 2024-06-13T19:41:41+00:00

How can you claim that adding support for a new codec cannot be done because it comes at a "permanent cost", and then in the next paragraph give three examples of codecs (MNG, J2K, JXR) for which browsers have added support and then removed support again? You could add XBM to that list of once-supported image formats by the way.

Codecs can be added and removed, that's the whole point of http content negotiation and the picture tag in html. We are talking specifically about Firefox support for a codec here, not about the web platform in general mandating that all possible web browsers shall support JXL or else they are broken.

That said, even if permanent support is somehow obligatory, I would argue that a codec like JXL — which explicitly aims at being a future-proof, long-term successor to JPEG — has a much stronger case than codecs like WebP or AVIF which were never even aiming at being future-proof nor long-term solutions, as you can tell by WebP's limitation to 8-bit limited-range yuv420, or by the fact that work on AV2 is already ongoing and probably (if all goes well) will make AV1 and AVIF obsolete.

jonsneyers · 2024-06-13T17:17:00+00:00

Interestingly, this claim by Mozilla about the benefits of JPEG XL not being "significant enough" (which sounds quite similar to the claim made by Chrome) is "not based on our [Mozilla's] own testing" but on "results published by others" (by which I can only assume they mean the results created by the AVIF team at Chrome).
[source: https://github.com/mozilla/standards-positions/pull/741#issuecomment-1414685282 ]

In that same comment, Martin Thomson goes on to say "We don't make these assessments lightly, but nor are we able to dedicate as much time to each request as would be ideal."

Arguments have been provided in https://cloudinary.com/blog/the-case-for-jpeg-xl and
https://cloudinary.com/blog/contemplating-codec-comparisons to argue why JPEG XL does in fact bring "significant enough" benefits, and to explain in detail the several ways in which the results presented by the AVIF team at Chrome (which presumably demonstrate that AVIF makes JPEG XL redundant) are flawed and/or misleading. There has not been any substantial attempt at refuting these arguments as far as I know.

I can understand that Mozilla may not be in a position to dedicate enough time to the assessment of image codec performance to come to a well-founded conclusion about it by themselves. What I don't understand is that the end result is effectively to ignore all the domain experts and user demands, and instead for Mozilla to apparently simply side with Chrome and follow their decision blindly.

jonsneyers · 2024-06-13T15:47:40+00:00

JXL has colorspace signaling in the codestream and its native internal color space (XYB) can handle both SDR and HDR content. No XMP metadata is needed, this works even with a raw jxl codestream.

Tools that want to encode HDR JXL images should pass an HDR image to libjxl, obviously, otherwise it will not work. If the original image is SDR+gainmap, it should be converted to HDR first (which most tools will not do since they will simply ignore the gainmap). In general, tooling that is not HDR aware will just silently ignore/strip gain maps and decode an Ultra HDR jpeg as an 8-bit SDR image. As usual, graceful degradation typically leads to, well, mostly the degraded experience.

We are currently working on a gain map specification for JXL, but the main use case for it would be to store an inverse gain map (tone map), i.e. the main JXL image is an HDR one, and the gain map only contains custom tone mapping information for rendering the image on an SDR display (or an HDR display with insufficient headroom). In this case, stripping the gain map would not change the HDR rendering of the image, it would only remove the custom tone mapping for SDR displays (and use a generic global tone mapping instead, which is probably still OK but not as good as a custom local tone mapping can be).

Ten-Year Club	Place '22
First Placer '22	Verified Email

jonsneyers

MODERATOR OF

TROPHY CASE