10 ms·

Chromium Has Merged JpegXL

451 points by thunderbong 10mo ago

jakkos 10mo ago
I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it. From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing? My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.
- speps 10mo ago
  It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.
  - a-french-anon 10mo ago
    Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits. The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats).
  - spider-mario 10mo ago
    It’s largely the same people.
- jacobp100 10mo ago
  JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.
  - londons_explore 10mo ago
    And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser. I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.
- out_of_protocol 10mo ago
  - avif is better at low bpp (low-quality images), terrible in lossless - jxl is better at high bpp, best in lossless mode
- jmillikin 10mo ago
  Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox. The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.
  - latexr 10mo ago
    > The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill: > Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog. https://www.youtube.com/watch?v=EvKTOHVGNbg https://www.youtube.com/watch?v=EvKTOHVGNbg
    - jmillikin 10mo ago
      I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type: * CNN (cnn.com): News-related photos on their front page * Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting * Amazon (amazon.com): Product categories on the front page (product images are in WebP) I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.
- coppsilgold 10mo ago
  JPEG XL has progressive decoding https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U
- archerx 10mo ago
  Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.
  - breppp 10mo ago
    unjustified preferential treatment over jpegxl a format google also had created
    - archerx 10mo ago
      They helped create jpegXL but they are not the sole owner like they are with webp. There is a difference.
      - breppp 10mo ago
        a better argument might be that chrome protects their own vs a research group in google switzerland, however as other mentioned the security implications of another unsafe binary parser in a browser is hardly worth it
        archerx 10mo ago
        Webp has had major vulnerabilities. https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/ https://blog.cloudflare.com/uncovering-the-hidden-webp-vulne...
        breppp 10mo ago
        which only strengthens my argument, webp seemed like some ad-hoc pet project in chrome, and that ended like most unsafe binary parsers, with critical vulnerabilities
        magicalist 10mo ago
        > webp seemed like some ad-hoc pet project in chrome FWIW webp came from the same "research group in google switzerland" that later developed jpegxl.
- rdsubhas 10mo ago
  > various "benchmarks" JpegXL seems just be flat out better than WebP The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc. JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF. For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up. But for what we all need – it's really necessary to start the JXL journey now.
  - Dylan16807 10mo ago
    > Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. Extra data transfer costs performance and battery life too.
  - chocolatkey 10mo ago
    Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images
- 3OCSzk 10mo ago
  1 black pixel of .webp is smaller than 1 black pixel of .jpegxl that is also smaller than 1 black pixel of .png so webp > jpegxl > png
viktorcode 10mo ago
Anyone knows if their implementation supports animations? This is a feature missing from Apple's
- adzm 10mo ago
  According to the chrome platform status page, yes! https://chromestatus.com/feature/5114042131808256 https://chromestatus.com/feature/5114042131808256 >>> - Progressive decoding for improved perceived loading performance - Support for wide color gamut, HDR, and high bit depth - Animation support
- nar001 10mo ago
  It does, I just tried it in Canary and the jxl test page did also show animations
- actionfromafar 10mo ago
  What, isn't this the cue for someone to explain that it's ironic webp is really a video format which is a bad image format, and now we have symmetry that JpegXL is a good image format which is bad video format? :-D (I don't know if any of this is true, but it sounds funny...)
  - account42 10mo ago
    Webp is also an incredibly bad animation format since it drops most of the inter-frame compression features of the video codec it was derived from.
- Latitude7973 10mo ago
  Yes, but it's not recommended - it does not have inter-frame compression, so it is significantly less efficient than just having a regular video file and slapping 'gif' on it.
  - 112233 10mo ago
    Do you know of a video format that supports progressive decoding?
adzm 10mo ago
https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.
- quikoa 10mo ago
  Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.
  - pixelesque 10mo ago
    Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.
    - adzm 10mo ago
      And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
      - deleted 10mo ago
        [deleted]
      - klglrksbjkt 10mo ago
        https://www.google.com/search?q=what+the+old+man+does+is+always+right https://www.google.com/search?q=what+the+old+man+does+is+alw...
        actionfromafar 10mo ago
        Hahaha perfect! Can't believe I never heard this story before.
LtdJorge 10mo ago
I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image). JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.
- adzm 10mo ago
  You have to adjust the CPU used parameter, not just quality, for AVIF. Though it can indeed be slow it should not be that slow, especially for a 1mp image. The defaults usually use a higher CPU setting for some reason. I have modest infrastructure that generates 2MP AVIF in a hundred ms or so.
  - LtdJorge 10mo ago
    I tested both WebP and AVIF with maximum CPU usage/effort. I have not tried the faster settings because I wanted the highest quality for small size, but for similar quality WebP blew AVIF out of the water. I also have both compiled with -O3 and -march=znver2 in GCC (same for rav1e's RUSTFLAGS) through my Gentoo profile.
    - adzm 10mo ago
      Maximum CPU between those two libs is not really comparable though. But quality is subjective and it sounds like webp worked best for you! Just saying though, there is little benefit in using the max CPU settings for avif. That's like comparing max CPU settings on zip vs xz!
- fishgoesblub 10mo ago
  rav1e has not had an actual update in performance or quality in years since funding got dropped. Use an encoder like aom, or svt-av1.
  - LtdJorge 10mo ago
carra 10mo ago
Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.
- Sammi 10mo ago
  You can really treat WebP as a universally available format in 2026. It is an old, boring, and safe format to use now. Browser support for WebP is excellent now. The last browser to add it was Safari 14 in September 16, 2020: https://caniuse.com/webp https://caniuse.com/webp It got into Windows 10 1809 in October 2018. Into MacOS Big Sur in November 2020. Wikipedia has a great list of popular software that supports it: https://en.wikipedia.org/wiki/WebP#Graphics_software https://en.wikipedia.org/wiki/WebP#Graphics_software
  - Y-bar 10mo ago
    Webp can be really annoying once you hit certain encoding edge cases. One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.
    - jdiff 10mo ago
      Just out of curiosity, what's the problem libwebp has with them? I wasn't aware of cases where any image format would just cross its arms and refuse point blank like that.
      - tr45872267 10mo ago
        Webp has a maximum pixel dimension size of 16383 x 16383.[0] [0] https://developers.google.com/speed/webp/faq#what_is_the_maximum_size_a_webp_image_can_be https://developers.google.com/speed/webp/faq#what_is_the_max...
      - 10mo ago
out_of_protocol 10mo ago
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW
- xnx 10mo ago
  > This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings. Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
  - lambdaone 10mo ago
    And even better if someone can implement the whole massive spec securely...
    - fsflover 10mo ago
      This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security. Works for me with Qubes OS.
      - itintheory 10mo ago
        Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
        eptcyka 10mo ago
        Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you. This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
deleted 10mo ago
[deleted]
einpoklum 10mo ago
Unfortunately, with Chromium dropping support for manifest-v2 extensions, and through that dropping proper support for uBlock Origin, I'm moving away from it. Not that that's easy, of course...
- igufrcybh 10mo ago
  [dead]
- YmiYugy 10mo ago
  With Chrome being by far the most popular browser, it gaining support is almost a precondition for jxl gaining traction on the web. Few would bother converting their images for Safari (and when it becomes enabled without a flag Firefox). So this is good news even for people who don't use Chromium.
bla3 10mo ago
It's a shame that JpegXL doesn't have a freely available spec.
- Latitude7973 10mo ago
  In general terms, it is a shame that thousands of ISO, IEC etc specifications and documents are behind a paywall.
  - bionhoward 10mo ago
    Yes! The paywalled SQL documents are a big annoyance
  - nathancahill 10mo ago
    I'm surprised there hasn't been a Z-Lib/Anna's like movement for spec documents. Given how tech savvy the default audience of those documents are.
    - OneDeuxTriSeiGo 10mo ago
      I mean anna's have most specs and if you know where to look there are IPFS and torrent sources for large portions of entire spec libraries.
    - account42 10mo ago
      For many relevant specs you can find "draft versions" that are essentially the final version without the official stamp on the open web so there isn't that much of a need.
- master-lincoln 10mo ago
  You could also say it's a sham to have non-public standards
- ksec 10mo ago
  IIRC it doesn't have a freely available "Final" spec. The Final Draft is available for free.
Findecanor 10mo ago
From my (limited) understanding, there is still a lot shared between JPEG and JPEG-XL. I wonder if this new implementation could be extended to incorporate support for the older JPEG format and if then total code size could be reduced.
- dabinat 10mo ago
  Not sure why you’re being downvoted… there is an issue open on the JPEG-XL Rust repo for this very feature. https://github.com/libjxl/jxl-rs/issues/513 https://github.com/libjxl/jxl-rs/issues/513
igufrcybh 10mo ago
[dead]
hbn 10mo ago
So is this another image format I'll download and be unable to use without converting because nothing supports it a la .webp?
- caminanteblanco 10mo ago
  I mean even Microsoft (that Titan of Lightning-Fast Development) has implemented a JPEG XL add-on, so now that Google's giving up the ghost, i think JPEG XL has a real chance. https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=US&ocid=pdpshare https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=U...
  - RobotToaster 10mo ago
    Only for win11
- thunderfork 10mo ago
  Yes, just like any new format, there's going to be an adoption period of about a decade before it reaches "ubiquitous-enough" support.
- llm_nerd 10mo ago
  What do you think doesn't support it? Affinity supports it. Photoshop supports it. Microsoft Photos supports it. Gimp supports it. Apple has had systemwide support for it since iOS 17+ / macOS 12+, including in Safari and basically any app that uses the system image functions. Chromium isn't on the bleeding edge here. They actually were when it first came out, but then retreated and waited, and now they're back again.
  - aniviacat 10mo ago
    Lots of stuft still doesn't support it, for example WhatsApp and Discord. WhatsApp doesn't even support WebP though. Hopefully, if they ever get around to adding WebP, they'll throw JXL in, too.
    - 10mo ago
RobotToaster 10mo ago
Reading the feature list of JpegXL on Wiki, it includes some interesting stuff like arbitrary numbers of channels for multi-spectral imaging and multi page documents, which for both better and worse starts to sound a lot like TIFF.
Mr_Minderbinder 10mo ago
Why does the current design paradigm in image coding formats emphasise supporting as many features as possible in order to have “one image format to rule them all”? You do not see this in audio and does anybody think that Opus and FLAC should be combined into one format? Does the fact that Opus does not support lossless encoding make it worse?
- upbeat_general 10mo ago
  From a user perspective it is nice to know that the person decoding will likely support a given format, both now and in the future. More use cases for a single popular format makes this more likely.

451 points by thunderbong 10mo ago

jakkos 10mo ago

I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it. From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing? My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.

speps 10mo ago
It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.
- a-french-anon 10mo ago
  Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits. The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats).
- spider-mario 10mo ago
  It’s largely the same people.
jacobp100 10mo ago
JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.
- londons_explore 10mo ago
  And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser. I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.
out_of_protocol 10mo ago
- avif is better at low bpp (low-quality images), terrible in lossless - jxl is better at high bpp, best in lossless mode
jmillikin 10mo ago
Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox. The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.
- latexr 10mo ago
  > The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill: > Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog. https://www.youtube.com/watch?v=EvKTOHVGNbg https://www.youtube.com/watch?v=EvKTOHVGNbg
  - jmillikin 10mo ago
    I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type: * CNN (cnn.com): News-related photos on their front page * Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting * Amazon (amazon.com): Product categories on the front page (product images are in WebP) I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.
coppsilgold 10mo ago
JPEG XL has progressive decoding https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U
archerx 10mo ago
Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.
- breppp 10mo ago
  unjustified preferential treatment over jpegxl a format google also had created
  - archerx 10mo ago
    They helped create jpegXL but they are not the sole owner like they are with webp. There is a difference.
    - breppp 10mo ago
      a better argument might be that chrome protects their own vs a research group in google switzerland, however as other mentioned the security implications of another unsafe binary parser in a browser is hardly worth it
      - archerx 10mo ago
        Webp has had major vulnerabilities. https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/ https://blog.cloudflare.com/uncovering-the-hidden-webp-vulne...
        breppp 10mo ago
        which only strengthens my argument, webp seemed like some ad-hoc pet project in chrome, and that ended like most unsafe binary parsers, with critical vulnerabilities
        magicalist 10mo ago
        > webp seemed like some ad-hoc pet project in chrome FWIW webp came from the same "research group in google switzerland" that later developed jpegxl.
rdsubhas 10mo ago
> various "benchmarks" JpegXL seems just be flat out better than WebP The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc. JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF. For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up. But for what we all need – it's really necessary to start the JXL journey now.
- Dylan16807 10mo ago
  > Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. Extra data transfer costs performance and battery life too.
- chocolatkey 10mo ago
  Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images
3OCSzk 10mo ago
1 black pixel of .webp is smaller than 1 black pixel of .jpegxl that is also smaller than 1 black pixel of .png so webp > jpegxl > png

viktorcode 10mo ago

Anyone knows if their implementation supports animations? This is a feature missing from Apple's

adzm 10mo ago
According to the chrome platform status page, yes! https://chromestatus.com/feature/5114042131808256 https://chromestatus.com/feature/5114042131808256 >>> - Progressive decoding for improved perceived loading performance - Support for wide color gamut, HDR, and high bit depth - Animation support
nar001 10mo ago
It does, I just tried it in Canary and the jxl test page did also show animations
actionfromafar 10mo ago
What, isn't this the cue for someone to explain that it's ironic webp is really a video format which is a bad image format, and now we have symmetry that JpegXL is a good image format which is bad video format? :-D (I don't know if any of this is true, but it sounds funny...)
- account42 10mo ago
  Webp is also an incredibly bad animation format since it drops most of the inter-frame compression features of the video codec it was derived from.
Latitude7973 10mo ago
Yes, but it's not recommended - it does not have inter-frame compression, so it is significantly less efficient than just having a regular video file and slapping 'gif' on it.
- 112233 10mo ago
  Do you know of a video format that supports progressive decoding?

adzm 10mo ago

https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.

quikoa 10mo ago
Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.
- pixelesque 10mo ago
  Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.
  - adzm 10mo ago
    And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
    - deleted 10mo ago
      [deleted]
    - klglrksbjkt 10mo ago
      https://www.google.com/search?q=what+the+old+man+does+is+always+right https://www.google.com/search?q=what+the+old+man+does+is+alw...
      - actionfromafar 10mo ago
        Hahaha perfect! Can't believe I never heard this story before.

LtdJorge 10mo ago

I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image). JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.

adzm 10mo ago
You have to adjust the CPU used parameter, not just quality, for AVIF. Though it can indeed be slow it should not be that slow, especially for a 1mp image. The defaults usually use a higher CPU setting for some reason. I have modest infrastructure that generates 2MP AVIF in a hundred ms or so.
- LtdJorge 10mo ago
  I tested both WebP and AVIF with maximum CPU usage/effort. I have not tried the faster settings because I wanted the highest quality for small size, but for similar quality WebP blew AVIF out of the water. I also have both compiled with -O3 and -march=znver2 in GCC (same for rav1e's RUSTFLAGS) through my Gentoo profile.
  - adzm 10mo ago
    Maximum CPU between those two libs is not really comparable though. But quality is subjective and it sounds like webp worked best for you! Just saying though, there is little benefit in using the max CPU settings for avif. That's like comparing max CPU settings on zip vs xz!
fishgoesblub 10mo ago
rav1e has not had an actual update in performance or quality in years since funding got dropped. Use an encoder like aom, or svt-av1.
- LtdJorge 10mo ago

carra 10mo ago

Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.

Sammi 10mo ago
You can really treat WebP as a universally available format in 2026. It is an old, boring, and safe format to use now. Browser support for WebP is excellent now. The last browser to add it was Safari 14 in September 16, 2020: https://caniuse.com/webp https://caniuse.com/webp It got into Windows 10 1809 in October 2018. Into MacOS Big Sur in November 2020. Wikipedia has a great list of popular software that supports it: https://en.wikipedia.org/wiki/WebP#Graphics_software https://en.wikipedia.org/wiki/WebP#Graphics_software
- Y-bar 10mo ago
  Webp can be really annoying once you hit certain encoding edge cases. One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.
  - jdiff 10mo ago
    Just out of curiosity, what's the problem libwebp has with them? I wasn't aware of cases where any image format would just cross its arms and refuse point blank like that.
    - tr45872267 10mo ago
      Webp has a maximum pixel dimension size of 16383 x 16383.[0] [0] https://developers.google.com/speed/webp/faq#what_is_the_maximum_size_a_webp_image_can_be https://developers.google.com/speed/webp/faq#what_is_the_max...
    - 10mo ago

out_of_protocol 10mo ago

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW

xnx 10mo ago
> This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings. Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
- lambdaone 10mo ago
  And even better if someone can implement the whole massive spec securely...
  - fsflover 10mo ago
    This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security. Works for me with Qubes OS.
    - itintheory 10mo ago
      Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
      - eptcyka 10mo ago
        Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you. This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.

deleted 10mo ago

[deleted]

einpoklum 10mo ago

Unfortunately, with Chromium dropping support for manifest-v2 extensions, and through that dropping proper support for uBlock Origin, I'm moving away from it. Not that that's easy, of course...

igufrcybh 10mo ago
[dead]
YmiYugy 10mo ago
With Chrome being by far the most popular browser, it gaining support is almost a precondition for jxl gaining traction on the web. Few would bother converting their images for Safari (and when it becomes enabled without a flag Firefox). So this is good news even for people who don't use Chromium.

bla3 10mo ago

It's a shame that JpegXL doesn't have a freely available spec.

Latitude7973 10mo ago
In general terms, it is a shame that thousands of ISO, IEC etc specifications and documents are behind a paywall.
- bionhoward 10mo ago
  Yes! The paywalled SQL documents are a big annoyance
- nathancahill 10mo ago
  I'm surprised there hasn't been a Z-Lib/Anna's like movement for spec documents. Given how tech savvy the default audience of those documents are.
  - OneDeuxTriSeiGo 10mo ago
    I mean anna's have most specs and if you know where to look there are IPFS and torrent sources for large portions of entire spec libraries.
  - account42 10mo ago
    For many relevant specs you can find "draft versions" that are essentially the final version without the official stamp on the open web so there isn't that much of a need.
master-lincoln 10mo ago
You could also say it's a sham to have non-public standards
ksec 10mo ago
IIRC it doesn't have a freely available "Final" spec. The Final Draft is available for free.

Findecanor 10mo ago

From my (limited) understanding, there is still a lot shared between JPEG and JPEG-XL. I wonder if this new implementation could be extended to incorporate support for the older JPEG format and if then total code size could be reduced.

dabinat 10mo ago
Not sure why you’re being downvoted… there is an issue open on the JPEG-XL Rust repo for this very feature. https://github.com/libjxl/jxl-rs/issues/513 https://github.com/libjxl/jxl-rs/issues/513

igufrcybh 10mo ago

[dead]

hbn 10mo ago

So is this another image format I'll download and be unable to use without converting because nothing supports it a la .webp?

caminanteblanco 10mo ago
I mean even Microsoft (that Titan of Lightning-Fast Development) has implemented a JPEG XL add-on, so now that Google's giving up the ghost, i think JPEG XL has a real chance. https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=US&ocid=pdpshare https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=U...
- RobotToaster 10mo ago
  Only for win11
thunderfork 10mo ago
Yes, just like any new format, there's going to be an adoption period of about a decade before it reaches "ubiquitous-enough" support.
llm_nerd 10mo ago
What do you think doesn't support it? Affinity supports it. Photoshop supports it. Microsoft Photos supports it. Gimp supports it. Apple has had systemwide support for it since iOS 17+ / macOS 12+, including in Safari and basically any app that uses the system image functions. Chromium isn't on the bleeding edge here. They actually were when it first came out, but then retreated and waited, and now they're back again.
- aniviacat 10mo ago
  Lots of stuft still doesn't support it, for example WhatsApp and Discord. WhatsApp doesn't even support WebP though. Hopefully, if they ever get around to adding WebP, they'll throw JXL in, too.
  - 10mo ago

RobotToaster 10mo ago

Reading the feature list of JpegXL on Wiki, it includes some interesting stuff like arbitrary numbers of channels for multi-spectral imaging and multi page documents, which for both better and worse starts to sound a lot like TIFF.

Mr_Minderbinder 10mo ago

Why does the current design paradigm in image coding formats emphasise supporting as many features as possible in order to have “one image format to rule them all”? You do not see this in audio and does anybody think that Opus and FLAC should be combined into one format? Does the fact that Opus does not support lossless encoding make it worse?

upbeat_general 10mo ago
From a user perspective it is nice to know that the person decoding will likely support a given format, both now and in the future. More use cases for a single popular format makes this more likely.