7 ms·

I'm curious how many HN people in 2026 have not yet heard of JPEG XL / jxl

by yboris 1mo ago

tosti 1mo ago
I'm curious why a PDF with a jxl in it takes ages to load.
- masfuerte 1mo ago
  If you're in a browser without native support maybe they implemented a jxl decoder in javascript.
etatoby 1mo ago
I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
- Macha 1mo ago
  The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF. Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
  - Sammi 1mo ago
    Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images. I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding. Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
    - Implicated 1mo ago
      > JpegXL will be the best of all worlds choice in a few years when software support is good. Where is the software support lacking other than the browsers at this point?
      - _bent 1mo ago
        The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
      - HappMacDonald 1mo ago
        File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
        spider-mario 1mo ago
        macOS and Windows’ respective file explorers and built-in image viewers both support it, as do Photoshop, GIMP, Krita and a few more. https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support https://en.wikipedia.org/wiki/JPEG_XL#Official_software_supp...
      - socalgal2 1mo ago
        I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL
        Sammi 1mo ago
        This is probably going to be the longest tail of them all. I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
  - radicality 1mo ago
    It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl
  - Dwedit 1mo ago
    Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.
  - trompetenaccoun 1mo ago
    There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif. There's a good visual comparison here: https://www.youtube.com/watch?v=SzsM4HMKmEI https://www.youtube.com/watch?v=SzsM4HMKmEI
    - bityard 1mo ago
      JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
      - spider-mario 1mo ago
        Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_martians https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
      - kekdkrjfjjwfj 1mo ago
        > According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably. Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.
- odo1242 1mo ago
  It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can. Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process. * it actually has better compression than PNG for this * and potentially AVIF too, but this is debated
  - farlight 1mo ago
    avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size. jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp. Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
    - encrypted_bird 1mo ago
      >Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?
      - pxoe 1mo ago
        JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
- BoingBoomTschak 1mo ago
  Lossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding. Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates. Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS. And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
  - juliobbv 1mo ago
    Dude... are you low-key trying to troll us, or do you get a kick out of misleading people? How can you manage to be confidently wrong this much? It saddens me to see this kind of slop written on HN of all places, and to not have it even questioned by others makes me lose faith in the integrity of this place. Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts. > especially AVIF that can't really do lossless RGB AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC). > webp ungodly smoothing There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking. > libaom is a reference codec thus slow libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues. > and not really interested in proper psy optimizations libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3]. > SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios. Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used. > Progressive decoding AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away! The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :) [1] https://halide.cx/iris/ https://halide.cx/iris/ [2] https://aomedia.googlesource.com/aom/+/refs/heads/av1-normative https://aomedia.googlesource.com/aom/+/refs/heads/av1-normat... [3] https://halide.cx/blog/improving-avif-in-open-source/ https://halide.cx/blog/improving-avif-in-open-source/ [4] https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-items https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-... [5] https://jpegxl.info/resources/progressive-loading-demo.html https://jpegxl.info/resources/progressive-loading-demo.html
- phkahler 1mo ago
  Higher bit-depth 10,12,16, float.
- Tuna-Fish 1mo ago
  At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal. jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
  - adgjlsfhk1 1mo ago
    The part of jpeg-xl I'm most excited for is when the 3d community starts standardizing the extra channels for depth maps, bump maps, roughness etc in the extra channels. You can use a single jpeg-xl as a full material system with progressive decoding for LOD and all the rest.
    - account42 1mo ago
      Does jxl support specifying what each channel contains rather than just having a channel number with a convention? I guess you could always add it as additional metadata if such a field doesn't exist already.
- spiralpolitik 1mo ago
  The big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
- HappMacDonald 1mo ago
  For one of my projects the important advantage was "lossless compression similar to Webp and Avif (far better than PNG)", while ALSO supporting > 16kpx dimensions where Webp and Avif appear to max out
- Semaphor 1mo ago
  One thing I’ve not seen mentioned: encoding speed. Encoding to webp (and I think Avif) is really slow, while at lower effort levels, JXL should easily be fast enough for on-the-fly.

I'm curious how many HN people in 2026 have not yet heard of JPEG XL / jxl

by yboris 1mo ago

I'm curious how many HN people in 2026 have not yet heard of JPEG XL / jxl

tosti 1mo ago

I'm curious why a PDF with a jxl in it takes ages to load.

masfuerte 1mo ago
If you're in a browser without native support maybe they implemented a jxl decoder in javascript.

etatoby 1mo ago

I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.

Macha 1mo ago
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF. Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
- Sammi 1mo ago
  Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images. I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding. Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
  - Implicated 1mo ago
    > JpegXL will be the best of all worlds choice in a few years when software support is good. Where is the software support lacking other than the browsers at this point?
    - _bent 1mo ago
      The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
    - HappMacDonald 1mo ago
      File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
      - spider-mario 1mo ago
        macOS and Windows’ respective file explorers and built-in image viewers both support it, as do Photoshop, GIMP, Krita and a few more. https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support https://en.wikipedia.org/wiki/JPEG_XL#Official_software_supp...
    - socalgal2 1mo ago
      I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL
      - Sammi 1mo ago
        This is probably going to be the longest tail of them all. I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
- radicality 1mo ago
  It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl
- Dwedit 1mo ago
  Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.
- trompetenaccoun 1mo ago
  There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif. There's a good visual comparison here: https://www.youtube.com/watch?v=SzsM4HMKmEI https://www.youtube.com/watch?v=SzsM4HMKmEI
  - bityard 1mo ago
    JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
    - spider-mario 1mo ago
      Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_martians https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
    - kekdkrjfjjwfj 1mo ago
      > According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably. Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.
odo1242 1mo ago
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can. Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process. * it actually has better compression than PNG for this * and potentially AVIF too, but this is debated
- farlight 1mo ago
  avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size. jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp. Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
  - encrypted_bird 1mo ago
    >Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?
    - pxoe 1mo ago
      JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
BoingBoomTschak 1mo ago
Lossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding. Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates. Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS. And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
- juliobbv 1mo ago
  Dude... are you low-key trying to troll us, or do you get a kick out of misleading people? How can you manage to be confidently wrong this much? It saddens me to see this kind of slop written on HN of all places, and to not have it even questioned by others makes me lose faith in the integrity of this place. Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts. > especially AVIF that can't really do lossless RGB AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC). > webp ungodly smoothing There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking. > libaom is a reference codec thus slow libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues. > and not really interested in proper psy optimizations libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3]. > SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios. Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used. > Progressive decoding AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away! The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :) [1] https://halide.cx/iris/ https://halide.cx/iris/ [2] https://aomedia.googlesource.com/aom/+/refs/heads/av1-normative https://aomedia.googlesource.com/aom/+/refs/heads/av1-normat... [3] https://halide.cx/blog/improving-avif-in-open-source/ https://halide.cx/blog/improving-avif-in-open-source/ [4] https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-items https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-... [5] https://jpegxl.info/resources/progressive-loading-demo.html https://jpegxl.info/resources/progressive-loading-demo.html
phkahler 1mo ago
Higher bit-depth 10,12,16, float.
Tuna-Fish 1mo ago
At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal. jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
- adgjlsfhk1 1mo ago
  The part of jpeg-xl I'm most excited for is when the 3d community starts standardizing the extra channels for depth maps, bump maps, roughness etc in the extra channels. You can use a single jpeg-xl as a full material system with progressive decoding for LOD and all the rest.
  - account42 1mo ago
    Does jxl support specifying what each channel contains rather than just having a channel number with a convention? I guess you could always add it as additional metadata if such a field doesn't exist already.
spiralpolitik 1mo ago
The big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
HappMacDonald 1mo ago
For one of my projects the important advantage was "lossless compression similar to Webp and Avif (far better than PNG)", while ALSO supporting > 16kpx dimensions where Webp and Avif appear to max out
Semaphor 1mo ago
One thing I’ve not seen mentioned: encoding speed. Encoding to webp (and I think Avif) is really slow, while at lower effort levels, JXL should easily be fast enough for on-the-fly.