And soon Firefox will include it in Stable. During October it will go from Safari only to majority coverage. Eventful month!
While AVIF may have a slight edge in some cases like in fairly lossy compression, you won't really go _wrong_ with JPEG XL (unless strongly CPU constrained) and I think the strength of the format is its extreme versatility as a "be all end all image format" for some time where comparative performance depending on functionality ranges from respectable to excellent. It can work as a replacement for AVIF, PNG, JPEG, WebP, even certain TIFF required scenarios (high bit depth, multichannel, layers) depending on use cases.
It's exciting to see JXL support being re-added in Chrome after being removed a while ago and them seemingly not being interested in supporting it [1].
I think JXL is a cool image format, but was being held back by the most popular browser not supporting it, limiting its use (in the web especially) by a lot.
Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.
Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.
Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.
A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.
I'm sure those implementers got their fair share of the Google profit or at least a nominal donation for doing most of the work of building out a feature enhancement
My favourite tidbit about the Amiga is that it was the first platform that got PNG support in all its web browsers: you just had to install the png.datatype.
Eh. WebKit, Blink, Gecko being the big ones, supporting Windows, Linux (and alikes — maybe one would consider Android separate in this context) and Darwin (in this context iOS/macOS is the same). Mostly 1:1.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
Yeah, and then 100 different apps can repackage the browser engine as an Electron app, each weigh 300+mb.
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Such an important piece of software does not want to subject itself to the packaging and support woes of shared libraries. There are security issues, maintainability issues, and much more headache by going with that approach.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.
There were obviously some internal politics going on—Google joined the Alliance for Open Media, a consortium of the who's who of the media/tech industry: Apple, Facebook, Microsoft, Amazon, Netflix, Nvidia… the list goes on. They supported AVIF as the next generation image format.
Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland.
Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.
Removed because having yet another giant C codec was a huge risk, re-added because the PDF Association chose JXL as their next image format so anyone rendering PDFs (including browsers) is now required to have it.
"Required" is a strong word. More than enough people use Chrome as a PDF viewer that if Google decided to not support JXL, you'd see ~0 PDFs with it.
Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.
I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.
Glad to see it happen. I'd prefer it there was just one format rather than both jxl and avif, but at least it's the final nail in the coffin of webp which seems to have accomplished little but annoy people for not much gain.
The wider ecosystem support is still far from commonplace, but it is slowly changing. iOS 18 wouldn't work with .jxl in Photos, but 27 does. Similarly, quick look and preview works fine on MacOS 27, thumbnails show up properly etc. I also found no issues with .jxl on linux, and image editors are slowly adding support as well.
Plain old jpg will still be everywhere for the next decade, but I'm glad that we finally have superior options with no real downsides, and without all the patent bullshit to boot.
Surely support is even worse for both .jxl and .avif? If the annoying thing about .webp was lack of support, I don't think .jxl nor .avif solve any of that - just the opposite.
One thing to note is that even when WebP did eventually get support in many places, it often look a very long time because there just wasn’t that much motive or interest to support it. So for years it was the weird format you’d accidentally download from the web and have little luck getting to work off-line.
The non-exhaustive table linked below shows how long it took for different programs to support different image formats since their introduction. Outside of Chrome, Chrome in disguise, and whatever has become of Firefox, adoption of JPEG XL has been far more enthusiastic than it ever has for WebP—or AVIF, for that matter. So we are very unlikely to have a long period when JPEG XL only works on the web and nowhere else.
Every time a new image format comes out, I think about the compatibility crisis between apps.
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
JPEG-XL is not particularly patent-laden and its license is correct for the use-case.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
That doesn’t seem related to the codec itself but rather how you fetch said image.
Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.
True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
Depends on who you listen to, or what you test it on. It goes either way, and avif is typically significantly better at small files sizes where loading speed (or saving data) is the priority.
> MacOS can take a long time to update with support for new formats.
Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].
When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.
It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s.
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
WIC is reasonably widely used since it's used by WPF to load images. The problem is that a plugin codec structure exposes you to bad codecs. We had a tool at work break because someone installed a fast image viewer that overrode the default WIC JPEG decoder with a faster one that crashed loading our tool's splash screen image.
Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however.
I think QuickTime 7 had that capability (I remember installing a codec to make it play wmv video) but Apple removed the plugin architecture in QuickTime X.
The tortoises have somehow outrun the hare because Safari still hasn't turned on progressive loading in libjxl (which had this feature since before Safari added the feature), while FF (non Android) and Chrome shipped with it enabled. The 3 year long chess clock is now flipped.
You can’t really do that with PNG today either, because of all the PNG optimizers that quantize images before encoding them to PNG for better compression.
You cannot tell it just from the extension either. If you like extensions, you can use a '.lossless.jxl'. And in general for most formats, you can use metadata to store that info (also doesn't guarantee anything)
That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.
This is indeed frustrating, though realistically not that big of a deal for most users, especially if you consider lossless as just highest quality. Though personally I think it makes sense to have different extensions by convention for lossless and animated images.
JPEG artifacts are literally a meme, normal people are aware of this stuff.
I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.
I've been wishing for years that all of these codecs with hybrid lossless/lossy modes would just add a single l to their file extensions, purely for the annoyance of it.
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
See I would think lossless is the one you have to specify. (Also, it stops being "large" when you extend this gripe to similar formats like AVIF and WebP.)
Drat! I hoped this was going to cover the internal battle where Google executives trying to stop JPEG XL and how engineers finally convinced them to change their minds.
My guess: the engineers didn’t win the argument. The executives just gave up once all the other browsers had added support.
> The executives just gave up once all the other browsers had added support.
The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.
It's interesting how different theories come about when there is a lack of information and a high degree of preexisting bias. Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format. However as industry adoption increased and a newer safe library appeared, the decision was changed. Also, note that while Google developed the new rust library, it wasn't the chrome team who made the investment.
> Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format.
As evidenced by what? When first rejecting JPEG XL, Google did share their reasoning, but security problems hardly figured in it.
JPEG XL is largely a Google effort including in creating the specification, the reference implementation and later a safer Rust implementation. Why would Google executives want to stop it? From what I gather it's Chrome engineers that didn't want it because it was huge, had little adoption (at the time), and was rather redundant with AVIF and WebP (for Web purposes). Not saying they didn't have related mandates from executives but they also have a lot of say in what goes in and what doesn't.
My guess is that Apple supporting it natively in iOS (there's an option in iPhone 16+ to save taken photos as JPEG-XL instead of Apple's proprietary format) likely also pushed the needle
They added enough fear/uncertainty/doubt around jpeg xl that no sane organization will adopt it now. God Google might decide to remove support again in 2027
WebP is 15 years old, and Google cares about it less than anybody else. Pretty much everybody else supports WebP but Google can’t even be bothered adding support for it to Google Docs.
Took them long enough with a few embarassing detours, but a welcome news nonetheless! Has anyone ~blogged about some of the internal dynamics that lead the G ship to course-correct, would be curious to read?
Taking photos in JPEG XL? That's what I meant; the consumer side is nice, but if everybody keeps taking AVIF, HEIC, and JPEGs, we're missing an important part. (Sure, smaller websites are nice too, but I can have that today with WebP, as CDNs need to serve multiple formats anyway.)
I have a feeling that progressive loaders got downgraded along the way for whatever reason. I remember seeing progressive JPEGs and PNGs also load... progressively. JPEG even often had a grayscale-like first layer.
Are they switching it on in Android Chrome? That would complete the picture of at least baseline support... eventually... when a decent percentage of Android phones actually get that version.
But Safari (MacOS or iOS) still doesn't support the progressive rendering shown here, nor animation, if caniuse is up to date:
Fun fact, I needed JPEG XL support for my C++ pipeline and I didn't feel like including any official libraries. Roughly $500 tokens later I had a fully working optimized JPEG XL spec compliant en/de/coder that outperformed the official codepaths (both cpp and rust) by 70% (lower runtime). Took literally 5 hours to build out. Can someone tell me what Google is doing?
About three years ago I had to find a replacement for old .jpg files and .png files.
The main two contenders were .avif and .webp. For a few reasons, I selected .avif and in hindsight I think it was the better, choice. Both would be objectively better than jpg or png.
With JPEG XL ... hmmm. AVIF is not perfect, in particular when the compression rate is very high I noticed that some photos lose a lot of intrinsic quality that is not instantly obvious; I noticed this when I took various pictures over the years from outdoors. Still, AVIF beats jpg and png just about on every metric when compression is required. With JPEG XL I guess I have to re-evaluate, but right now I am still sticking to avif. The two factors that will be important for me is compression ratio and quality. I am ok with a bit of loss of quality, if the compression is better, but I am not sure JPEG XL beats AVIF here clearly either, so I am not sure what to do with JPEG XL.
Both JPEG XL and WebP far exceed AVIF when it comes to lossless. For lossy, AVIF used to do better at low quality and JPEG XL at high quality. But apparently AV1 encoders have improved a lot since then, closing the distance. An article comparing the two was posted recently:
The author, who has worked on said AV1 encoders, has expressed doubt that JPEG XL encoders could improve much with only reasonable amounts of effort, but that was also only their personal (if educated) guess. With JPEG XL finally seeing adoption on the web, we will hopefully see work on the reference encoder resume in earnest soon.
So for now, I’d say you’re fine with AVIF. Unless you’re doing lossless, because AVIF sucks at lossless. (And JPEG XL has the unique feature of supporting lossless JPEG transcoding, too.)
I thing the endgame is lossless PNG with 16bit color components with basic compression like gzip or at best bzip2. Or a format without the weirdness of PNG 'line based loading' which is obsolete nowdays. The "expensive part", apart from the compression algorithm, being the meta data storage without kludge.
>without the weirdness of PNG 'line based loading' which is obsolete nowdays
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
These days I favour lossless WEBP instead of PNG. I often save around 30%~40% of file size compared to PNG, especially when the PNG is encoded with lots of bits per pixel (i.e 48 bits or 24 bits).
Oh hell no. HDR is already bad enough in Youtube on iOS where there seems to be no way to turn it off - you tune your brightness to something decent in bed... and then some video by some showoff dingus scrolls across the feed frying your eyeballs.
Fuck HDR or at the very least give people an option to turn it off!
Mobile Firefox let's me add Stylus and I assume other extensions like whatever the modern Greasemonkey is. So at least one of the good mobile browsers does support it.
If you're using a mobile browser without extension support, you should tell the devs of it to work on that.
I will say windows implementation of HDR - at least the way Chrome handles it within Windows is somewhat of an abomination - so I'm sure Apple's iOS is just as poor!
but sometimes it's not HDRs fault - it's just the segura effect. People with cameras exceeding their capability levels, not understanding what you need to do after you shoot video in LOG.
I mix multi-monitor some-HDR some-SDR in Windows, it's bad.
I do not know if JPEG XL is competitive with AVIF for very compressed images, because that is mostly a concern for those who want to host at a minimum cost Web pages with embedded images. I assume that AVIF must be better for that purpose.
On the other hand, AVIF cannot compete with JPEG XL for high-quality photographs, which is something much more important for me, because it is a format suitable for storing my own photographs and it is a format that would make me appreciate positively a Web site that would have beautiful images in this format.
That isn’t my experience. I tried compressing conference proceedings into thumbnails with tiny file size and for this purpose I found that JPEGXL is far better than AVIF
While AVIF may have a slight edge in some cases like in fairly lossy compression, you won't really go _wrong_ with JPEG XL (unless strongly CPU constrained) and I think the strength of the format is its extreme versatility as a "be all end all image format" for some time where comparative performance depending on functionality ranges from respectable to excellent. It can work as a replacement for AVIF, PNG, JPEG, WebP, even certain TIFF required scenarios (high bit depth, multichannel, layers) depending on use cases.
I think JXL is a cool image format, but was being held back by the most popular browser not supporting it, limiting its use (in the web especially) by a lot.
[1]: https://issues.chromium.org/issues/40270698
https://security.snyk.io/vuln/?search=libjxl
I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.
Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.
Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.
Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.
A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.
https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...
right?
I have a feeling now JXL is here to stay, finally.
Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library
That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Good jerb.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.
Removed because no one from Google benifits from supporting it then.
Re-added because someone could get a promotion by supporting it now.
Do you mean the users of the browsers not benefitting, or specific Google employees/stakeholders?
They always abandon shit like this.
Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland.
Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.
Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.
I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.
Removed because trillion dollar advertising company don't bother, which also happens to be the browser vendor monopoly.
How many man-hour effort does it take to create jxl-rs ?
https://github.com/libjxl/jxl-rs/graphs/contributors
Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940
JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208
Chrome Jpegxl Issue Reopened - https://news.ycombinator.com/item?id=46033330
The case agains JPEG XL - https://news.ycombinator.com/item?id=49690554
The wider ecosystem support is still far from commonplace, but it is slowly changing. iOS 18 wouldn't work with .jxl in Photos, but 27 does. Similarly, quick look and preview works fine on MacOS 27, thumbnails show up properly etc. I also found no issues with .jxl on linux, and image editors are slowly adding support as well.
Plain old jpg will still be everywhere for the next decade, but I'm glad that we finally have superior options with no real downsides, and without all the patent bullshit to boot.
Discord Mobile absolutely supports animated WebP (in fact I just tried uploading one to make sure I wasn't hallucinating here).
The non-exhaustive table linked below shows how long it took for different programs to support different image formats since their introduction. Outside of Chrome, Chrome in disguise, and whatever has become of Firefox, adoption of JPEG XL has been far more enthusiastic than it ever has for WebP—or AVIF, for that matter. So we are very unlikely to have a long period when JPEG XL only works on the web and nowhere else.
https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong...
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it.
> you just truncate the output stream at the right proportion of pixel data
Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header?
Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.
The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
The format is designed to be as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats.
For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations.
I have not read that many direct comparisons here.
Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].
When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.
[1]: https://webkit.org/blog/14445/webkit-features-in-safari-17-0...
[2]: "iPhone 17 Pro’s Camera Leap: JPEG‑XL, Cleaner Shots, and Pro Filmmaking Tools" - https://modernengineeringmarvels.com/2025/09/19/iphone-17-pr...
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
JPEG artifacts are literally a meme, normal people are aware of this stuff.
I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.
perhaps use .ll.jxl to indicate "lossless jpegxl" informally?
prior art: I've been using .frontmatter.md or .fm.md for markdown files with frontmatter
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
Does the one at the end of .JXL count toward the total? Nobody knows what it stands for anyway.
Like files.tar.xz may be decompressed with xz and then extracted with tar to get the directory "files".
I think in your case .md.fm would be a greater fit, as the front matter is read first. Or just .fmd
My guess: the engineers didn’t win the argument. The executives just gave up once all the other browsers had added support.
The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.
As evidenced by what? When first rejecting JPEG XL, Google did share their reasoning, but security problems hardly figured in it.
JPEG XL is largely a Google effort including in creating the specification, the reference implementation and later a safer Rust implementation. Why would Google executives want to stop it? From what I gather it's Chrome engineers that didn't want it because it was huge, had little adoption (at the time), and was rather redundant with AVIF and WebP (for Web purposes). Not saying they didn't have related mandates from executives but they also have a lot of say in what goes in and what doesn't.
Have to stick with AVIF which supports up to 12 bits.
I’ll see myself out.
But Safari (MacOS or iOS) still doesn't support the progressive rendering shown here, nor animation, if caniuse is up to date:
https://caniuse.com/jpegxl
Not to be a downer — it's one necessary step on the road.
One to embody power, the other one to crave it?
I'm confused about the connection.
The main two contenders were .avif and .webp. For a few reasons, I selected .avif and in hindsight I think it was the better, choice. Both would be objectively better than jpg or png.
With JPEG XL ... hmmm. AVIF is not perfect, in particular when the compression rate is very high I noticed that some photos lose a lot of intrinsic quality that is not instantly obvious; I noticed this when I took various pictures over the years from outdoors. Still, AVIF beats jpg and png just about on every metric when compression is required. With JPEG XL I guess I have to re-evaluate, but right now I am still sticking to avif. The two factors that will be important for me is compression ratio and quality. I am ok with a bit of loss of quality, if the compression is better, but I am not sure JPEG XL beats AVIF here clearly either, so I am not sure what to do with JPEG XL.
https://news.ycombinator.com/item?id=49690554
The author, who has worked on said AV1 encoders, has expressed doubt that JPEG XL encoders could improve much with only reasonable amounts of effort, but that was also only their personal (if educated) guess. With JPEG XL finally seeing adoption on the web, we will hopefully see work on the reference encoder resume in earnest soon.
So for now, I’d say you’re fine with AVIF. Unless you’re doing lossless, because AVIF sucks at lossless. (And JPEG XL has the unique feature of supporting lossless JPEG transcoding, too.)
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
And lossless jpeg-xl exceeds your idea
50 times smaller than JPEG 2000.
Oh hell no. HDR is already bad enough in Youtube on iOS where there seems to be no way to turn it off - you tune your brightness to something decent in bed... and then some video by some showoff dingus scrolls across the feed frying your eyeballs.
Fuck HDR or at the very least give people an option to turn it off!
If you're using a mobile browser without extension support, you should tell the devs of it to work on that.
but sometimes it's not HDRs fault - it's just the segura effect. People with cameras exceeding their capability levels, not understanding what you need to do after you shoot video in LOG.
I mix multi-monitor some-HDR some-SDR in Windows, it's bad.
AVIF is still better at 1 bit per pixel and less. (JPEGXL is more efficient at more than that.) Is it possible for JPEGXL to beat that?
On the other hand, AVIF cannot compete with JPEG XL for high-quality photographs, which is something much more important for me, because it is a format suitable for storing my own photographs and it is a format that would make me appreciate positively a Web site that would have beautiful images in this format.