6 ms·

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 w

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 9mo 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 9mo ago
  And even better if someone can implement the whole massive spec securely...
  - fsflover 9mo 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 9mo 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 9mo 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.
        fsflover 9mo ago
        GPU acceleration is coming: https://github.com/QubesOS/qubes-issues/issues/8552 https://github.com/QubesOS/qubes-issues/issues/8552 > Do you hate using most hardware? Nobody uses "most hardware". You may be unlucky with your hardware, then it's a problem. Or you can specifically buy hardware working with the OS you want. > Do you like using Xorg? What's wrong with Xorg?
        eptcyka 9mo ago
        > What's wrong with Xorg? Lock screens that crash. Lock screens that can’t handle input from a yubikey?
        fsflover 9mo ago
        There are no crashes on lock screen with Qubes. Concerning Yubikey, see this: https://doc.qubes-os.org/en/latest/user/security-in-qubes/mfa.html https://doc.qubes-os.org/en/latest/user/security-in-qubes/mf...
      - fsflover 9mo ago
        Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 It's slow for tasks requiring GPU, but allowing GPU for chosen, trusted VMs is planned: https://github.com/QubesOS/qubes-issues/issues/8552 https://github.com/QubesOS/qubes-issues/issues/8552
      - JCattheATM 9mo ago
        Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
        fsflover 9mo ago
        When was the last Flatpak escape? Last VM escape from VT-d virtualization, which Qubes uses by default, was found in 2006 by the Qubes founder, https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software)
        JCattheATM 9mo ago
        The most recent VM escape from VT-d virtualization was in 2022[0]. Escapes are not the only vulnerability. QSB-108 allows for reading the memory of other qubes running on the host[1]. [0] https://nvd.nist.gov/vuln/detail/CVE-2020-15565 https://nvd.nist.gov/vuln/detail/CVE-2020-15565 [1] https://www.qubes-os.org/news/2025/07/11/qsb-108/ https://www.qubes-os.org/news/2025/07/11/qsb-108/
        fsflover 9mo ago
        Apart from the fact that this is extremely rare, the first vulnerability is not a complete escape. For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach. Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology, since they are the problem of CPUs. Nothing can help here, so this is irrelevant to this discussion. Except that Qubes Air will save you in the future: https://www.qubes-os.org/news/2018/01/22/qubes-air/ https://www.qubes-os.org/news/2018/01/22/qubes-air/
        JCattheATM 9mo ago
        > Apart from the fact that this is extremely rare, So are bubblewrap escapes, which is the sandbox flatpak uses. > the first vulnerability is not a complete escape. It could potentially lead to one, and being able to obtain information from other VMs defeats much of the point of isolation, and so defeats much of the point of why people use qubes. > For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach. That's not true. Strong MAC would suffice, no VT-d needed. > Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology Of course they do, in fact they have more to do with it than solutions like flatpak, which is why Qubes releases security advisories and patches to address those vulnerabilities.
    - lern_too_spel 9mo ago
      Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
      - fsflover 9mo ago
        If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
        lern_too_spel 9mo ago
        The web page you are visiting contains personal information, and that is where the mischief can be made. All that is required is for the website to incorrectly trust an image, either by not sanitizing a user-uploaded image or by embedding a third party image. Both trust bugs are rampant on the web, and both have caused problems in the past. Adding an improperly vetted image decoder is a sure-fire way to get exploit authors salivating.
        fsflover 9mo ago
        > The web page you are visiting contains personal information, and that is where the mischief can be made. This is a weird threat model. You trust some website with your personal information but you don't trust that images they embed are trusted and will not attack you. Nothing will save you here except switching off showing pictures, which you can also do on Qubes. I would say, if they really embed malicious images, then they probably have other problems with security, which nothing you run can help with.
        lern_too_spel 9mo ago
        > Nothing will save you here except switching off showing pictures Or having a trustable image decoder, which is what web browsers actually do. This is a basic requirement that you are proposing to do away with by instead not showing images at all.
  - JyrkiAlakuijala 9mo ago
    Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality. JPEG XL is not that massive. JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec. A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however. A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras. A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers. The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
- adgjlsfhk1 9mo ago
  The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)
  - aktau 9mo ago
    This is new to me. Can you elaborate please? Perhaps a link to somewhere showcasing this (and contrasting this to other solutions).
    - adgjlsfhk1 9mo ago
      See https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-format/41155 https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-for.... TLDR is that one of the really interesting things JPEG-XL adds is the ability to have an arbitrary number of non-color channels. The current solution is generally to use separate grayscale images for each extra thing you want to store, which is inefficient since it loses the ability to compress the correlation between the separate channels. Another example usecase would be capturing images at 10 different wavelengths rather than the typical RGB.
- hulitu 9mo ago
  > Big improvement if JPEG and PNG can be replaced by one codec. By one ? Ten maybe: webp, avif, ...
charcircuit 9mo ago
This doesn't use hardware accelerated decoders and encoders.
Nathanba 9mo ago
what exactly is this website trying to do? https://i.imgur.com/Q8JGYK3.png https://i.imgur.com/Q8JGYK3.png
- MrGilbert 9mo ago
  Maybe some form of fingerprinting for ads?
- stronglikedan 9mo ago
  I don't get any of that. Maybe you have a malicious extension installed?
smusamashah 9mo ago
JPEG at lowest quality looks much better here https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#what_quality_points_ https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#wha...
- daemonologist 9mo ago
  Keep in mind that lowest JPEG is 3-4x the size of the lowest JXL and AVIF - similar to the size of their "med-low" (top row).
- cfreksen 9mo ago
  That means that SSIMULACRA2 does not capture quality perfectly. Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with. In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF. After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.
lern_too_spel 9mo ago
Chromium is not using libjxl, which is the decoder that is evaluated in this article. The SVT encoder is much faster than the AOM encoder for AVIF.
- deleted 9mo ago
  [deleted]

xnx 9mo 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 9mo ago
And even better if someone can implement the whole massive spec securely...
- fsflover 9mo 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 9mo 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 9mo 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.
      - fsflover 9mo ago
        GPU acceleration is coming: https://github.com/QubesOS/qubes-issues/issues/8552 https://github.com/QubesOS/qubes-issues/issues/8552 > Do you hate using most hardware? Nobody uses "most hardware". You may be unlucky with your hardware, then it's a problem. Or you can specifically buy hardware working with the OS you want. > Do you like using Xorg? What's wrong with Xorg?
        eptcyka 9mo ago
        > What's wrong with Xorg? Lock screens that crash. Lock screens that can’t handle input from a yubikey?
        fsflover 9mo ago
        There are no crashes on lock screen with Qubes. Concerning Yubikey, see this: https://doc.qubes-os.org/en/latest/user/security-in-qubes/mfa.html https://doc.qubes-os.org/en/latest/user/security-in-qubes/mf...
    - fsflover 9mo ago
      Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 It's slow for tasks requiring GPU, but allowing GPU for chosen, trusted VMs is planned: https://github.com/QubesOS/qubes-issues/issues/8552 https://github.com/QubesOS/qubes-issues/issues/8552
    - JCattheATM 9mo ago
      Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
      - fsflover 9mo ago
        When was the last Flatpak escape? Last VM escape from VT-d virtualization, which Qubes uses by default, was found in 2006 by the Qubes founder, https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software)
        JCattheATM 9mo ago
        The most recent VM escape from VT-d virtualization was in 2022[0]. Escapes are not the only vulnerability. QSB-108 allows for reading the memory of other qubes running on the host[1]. [0] https://nvd.nist.gov/vuln/detail/CVE-2020-15565 https://nvd.nist.gov/vuln/detail/CVE-2020-15565 [1] https://www.qubes-os.org/news/2025/07/11/qsb-108/ https://www.qubes-os.org/news/2025/07/11/qsb-108/
        fsflover 9mo ago
        Apart from the fact that this is extremely rare, the first vulnerability is not a complete escape. For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach. Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology, since they are the problem of CPUs. Nothing can help here, so this is irrelevant to this discussion. Except that Qubes Air will save you in the future: https://www.qubes-os.org/news/2018/01/22/qubes-air/ https://www.qubes-os.org/news/2018/01/22/qubes-air/
        JCattheATM 9mo ago
        > Apart from the fact that this is extremely rare, So are bubblewrap escapes, which is the sandbox flatpak uses. > the first vulnerability is not a complete escape. It could potentially lead to one, and being able to obtain information from other VMs defeats much of the point of isolation, and so defeats much of the point of why people use qubes. > For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach. That's not true. Strong MAC would suffice, no VT-d needed. > Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology Of course they do, in fact they have more to do with it than solutions like flatpak, which is why Qubes releases security advisories and patches to address those vulnerabilities.
  - lern_too_spel 9mo ago
    Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
    - fsflover 9mo ago
      If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
      - lern_too_spel 9mo ago
        The web page you are visiting contains personal information, and that is where the mischief can be made. All that is required is for the website to incorrectly trust an image, either by not sanitizing a user-uploaded image or by embedding a third party image. Both trust bugs are rampant on the web, and both have caused problems in the past. Adding an improperly vetted image decoder is a sure-fire way to get exploit authors salivating.
        fsflover 9mo ago
        > The web page you are visiting contains personal information, and that is where the mischief can be made. This is a weird threat model. You trust some website with your personal information but you don't trust that images they embed are trusted and will not attack you. Nothing will save you here except switching off showing pictures, which you can also do on Qubes. I would say, if they really embed malicious images, then they probably have other problems with security, which nothing you run can help with.
        lern_too_spel 9mo ago
        > Nothing will save you here except switching off showing pictures Or having a trustable image decoder, which is what web browsers actually do. This is a basic requirement that you are proposing to do away with by instead not showing images at all.
- JyrkiAlakuijala 9mo ago
  Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality. JPEG XL is not that massive. JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec. A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however. A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras. A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers. The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
adgjlsfhk1 9mo ago
The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)
- aktau 9mo ago
  This is new to me. Can you elaborate please? Perhaps a link to somewhere showcasing this (and contrasting this to other solutions).
  - adgjlsfhk1 9mo ago
    See https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-format/41155 https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-for.... TLDR is that one of the really interesting things JPEG-XL adds is the ability to have an arbitrary number of non-color channels. The current solution is generally to use separate grayscale images for each extra thing you want to store, which is inefficient since it loses the ability to compress the correlation between the separate channels. Another example usecase would be capturing images at 10 different wavelengths rather than the typical RGB.
hulitu 9mo ago
> Big improvement if JPEG and PNG can be replaced by one codec. By one ? Ten maybe: webp, avif, ...

charcircuit 9mo ago

This doesn't use hardware accelerated decoders and encoders.

Nathanba 9mo ago

what exactly is this website trying to do? https://i.imgur.com/Q8JGYK3.png https://i.imgur.com/Q8JGYK3.png

MrGilbert 9mo ago
Maybe some form of fingerprinting for ads?
stronglikedan 9mo ago
I don't get any of that. Maybe you have a malicious extension installed?

smusamashah 9mo ago

JPEG at lowest quality looks much better here https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#what_quality_points_ https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#wha...

daemonologist 9mo ago
Keep in mind that lowest JPEG is 3-4x the size of the lowest JXL and AVIF - similar to the size of their "med-low" (top row).
cfreksen 9mo ago
That means that SSIMULACRA2 does not capture quality perfectly. Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with. In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF. After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.

lern_too_spel 9mo ago

Chromium is not using libjxl, which is the decoder that is evaluated in this article. The SVT encoder is much faster than the AOM encoder for AVIF.

deleted 9mo ago
[deleted]