As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties.
The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Nah, google paved the way forward with vital developments like WebGPU und import maps. I stopped using and supporting Firefox because they refused to improve the internet.
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface?
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
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.
Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
I am using .avif since some years; all my old .jpg
and .png files have been pretty much replaced by
.avif, in particular fotos. I am not saying .avif is
perfect, but IMO it is much better than .jpg or
.avif.
I could have gone .webp or perhaps jpeg-xl but at the
end of the day, I am quite happy with .avif as it is.
As for JPEG XL - I think the problem here is ... Google.
Google dictates de-facto web-standards onto us. This is
really bad. I don't want a commercial entity control my
digital life.
For making compact high-quality jpeg files, consider trying jpegli[1], it does an impressive job.
More specifically, if I try a bunch of AVIF quantization options and manually pick the one that appears visually lossless, it beats jpegli, but if I select a quantization option that always looks visually lossless with AVIF, jpegli will win the average size, because I need to use some headroom for images that AVIF does less well on.
It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence).
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are.
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
How‘s that possible? JPEG-XL stores image files, right? But RAW files are not images in the same sense. They haven‘t even been demosaiced. Or are Apple RAWs different?
Edit: I should have googled. apple‘s ProRAW does this, which isn‘t a RAW file in the classic sense.
JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere.
That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.
To address selected claims made in the post:
• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).
• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.
• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).
So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.
Quick reminder that it's not "Google" that killed JXL before, it was the Chrome team. Jpeg XL was designed by a Google engineer (JyrkiAlakuijala here) who is not part of the Chrome team, but in Google Research in the Zurich office while the Chrome team, although it has offices all around the world, at its core is very insular and lives in the Mountain View bubble.
One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched.
Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.
Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.
Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.
Good, but mass adoption is a lot slower in sites than in browsers it seems. It's like pulling teeth making sites to actually support even AVIF which is already widely supported in browsers. A ton of inertia even on sites like GitHub and GitLab. Try using AVIF on Wikipedia? Tough luck.
Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.
Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.
39 comments
[ 17.6 ms ] story [ 60.5 ms ] threadThe insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes
Thats a serious high-res image
Chromium Team Re-Opens JPEG XL Feature Ticket https://news.ycombinator.com/item?id=46018994
FSF Slams Google over Dropping JPEG-XL in Chrome https://news.ycombinator.com/item?id=35589179
Google set to deprecate JPEG XL support in Chrome 110 https://news.ycombinator.com/item?id=33399940
Chromium jpegxl issue closed as won't fix https://news.ycombinator.com/item?id=40407475
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
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.
Well tbf, the only time I ever hear about JPEG XL is when people complain about Chrome not having it. I think that might be its only actual use case.
I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif.
I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is.
As for JPEG XL - I think the problem here is ... Google. Google dictates de-facto web-standards onto us. This is really bad. I don't want a commercial entity control my digital life.
going crazy reading this sentence
More specifically, if I try a bunch of AVIF quantization options and manually pick the one that appears visually lossless, it beats jpegli, but if I select a quantization option that always looks visually lossless with AVIF, jpegli will win the average size, because I need to use some headroom for images that AVIF does less well on.
1: https://github.com/google/jpegli
https://www.youtube.com/watch?v=w7UDJUCMTng
[0] https://issues.chromium.org/issues/40168998#comment507
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
That this is working out is a combination of wishful thinking and getting lucky.
Edit: I should have googled. apple‘s ProRAW does this, which isn‘t a RAW file in the classic sense.
That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.
To address selected claims made in the post:
• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).
• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.
• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).
So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.
Encoding and decoding JPEG XL file is: #djxl input.jxl output.png.
Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.
Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.
Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.
So basically JXL is only being pushed to Chrome within Google because GCP have large clients that benefits from this and want this to be default.
Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.
Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.