3 ms·

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 im

by 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.
  - dchest 1mo ago
    It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
  - farlight 1mo ago
    Not sure imagemagick supports lossless transcoding. This old discussion from 2021 mentions that it didn't (in 2021): https://github.com/dlemstra/Magick.NET/discussions/872 https://github.com/dlemstra/Magick.NET/discussions/872 cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked: $ cjxl src.jpg out.jxl (some output) $ djxl out.jxl rev.jpg (more output) $ cmp src.jpg rev.jpg (no output: files identical)
  - shakna 1mo ago
    Image Magick re-encodes into an internal format, before output. If reproducibility is the goal, I'm afraid it just isn't the right tool. (The IR used to be PixelPacket. Not sure how modern versions handle it.)
- account42 1mo ago
  > Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. Last I checked cwebp still messed up the color space when converting from png so be careful how you use it.
mananaysiempre 1mo ago
> [JPEG XL can] display much larger images than AVIF can Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
- sb057 1mo ago
  Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.
  - mananaysiempre 1mo ago
    I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.
    - account42 1mo ago
      Technically, progressive JPEG is a kind of limited pyramid storage and some viewers do take advantage of that do decode downscaled images quickly.
danielheath 1mo ago
One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/#what-about-progressive-rendering-instead-of-responsive-images https://jakearchibald.com/2025/present-and-future-of-progres... ). If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels. A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb. The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend. Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
- jaffathecake 1mo ago
  I don't think this is going to work out. With the way progressive loading works in JXL, you don't really hit "good looking" points aside from at DC resolution.
  - account42 1mo ago
    Just being able to get 1/2, 1/4 or 1/8th of the image resolution would already cover most of the srcset use case and the results are good enough for many existing image decoders to already use this optimization for the decoding if not the network part.
  - danielheath 1mo ago
    I did some quick testing with `cjxl --progressive`, different quality levels, and https://google.github.io/attention-center/ https://google.github.io/attention-center/ A 1536w / 2048h jpg selfie: 244kb Progressive JXL at quality=70: 151kb Loaded 7kb of that file: looked okay up to approx 130px wide. The first 18kb of that file was a suitable thumbnail up to approx 210px wide. The first 50kb looked okay up to 300px wide. The first 75kb looked okay up to 600px wide. Maybe I need to do a lot more testing, but this seems to work alright?
bawolff 1mo ago
of course these are all fairly controversial claims - people dispute it compresses meaningfully better the types of images typically found on the web. - progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s. -flexibility in file formats is usually a bad thing. look at tiff. personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.
- trompetenaccoun 1mo ago
  Disagree with the second point. For one, there are many parts of the world where bandwidth still is an issue, either due to lack of infrastructure or because common people in those places can't afford better connections. This isn't going to change any time soon because although given bandwidth goes up over time, so do the file sizes websites serve. And even then, I'm posting this through a super fast connection, with which I still occasionally experience loading issues when my VPN acts up, because I live in a place with extreme censorship - which is on the rise worldwide. Generally, the approach should always be to prioritize files loading as fast as possible.
  - bawolff 1mo ago
    I agree there are exceptions on that point. Its just now its probably useful to like 5% of the average website's viewers, where 20 years ago it was useful to 95% of users.

by odo1242 1mo ago

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.
- dchest 1mo ago
  It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
- farlight 1mo ago
  Not sure imagemagick supports lossless transcoding. This old discussion from 2021 mentions that it didn't (in 2021): https://github.com/dlemstra/Magick.NET/discussions/872 https://github.com/dlemstra/Magick.NET/discussions/872 cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked: $ cjxl src.jpg out.jxl (some output) $ djxl out.jxl rev.jpg (more output) $ cmp src.jpg rev.jpg (no output: files identical)
- shakna 1mo ago
  Image Magick re-encodes into an internal format, before output. If reproducibility is the goal, I'm afraid it just isn't the right tool. (The IR used to be PixelPacket. Not sure how modern versions handle it.)
account42 1mo ago
> Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. Last I checked cwebp still messed up the color space when converting from png so be careful how you use it.

mananaysiempre 1mo ago

> [JPEG XL can] display much larger images than AVIF can Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.

sb057 1mo ago
Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.
- mananaysiempre 1mo ago
  I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.
  - account42 1mo ago
    Technically, progressive JPEG is a kind of limited pyramid storage and some viewers do take advantage of that do decode downscaled images quickly.

danielheath 1mo ago

One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/#what-about-progressive-rendering-instead-of-responsive-images https://jakearchibald.com/2025/present-and-future-of-progres... ). If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels. A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb. The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend. Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.

jaffathecake 1mo ago
I don't think this is going to work out. With the way progressive loading works in JXL, you don't really hit "good looking" points aside from at DC resolution.
- account42 1mo ago
  Just being able to get 1/2, 1/4 or 1/8th of the image resolution would already cover most of the srcset use case and the results are good enough for many existing image decoders to already use this optimization for the decoding if not the network part.
- danielheath 1mo ago
  I did some quick testing with `cjxl --progressive`, different quality levels, and https://google.github.io/attention-center/ https://google.github.io/attention-center/ A 1536w / 2048h jpg selfie: 244kb Progressive JXL at quality=70: 151kb Loaded 7kb of that file: looked okay up to approx 130px wide. The first 18kb of that file was a suitable thumbnail up to approx 210px wide. The first 50kb looked okay up to 300px wide. The first 75kb looked okay up to 600px wide. Maybe I need to do a lot more testing, but this seems to work alright?

bawolff 1mo ago

of course these are all fairly controversial claims - people dispute it compresses meaningfully better the types of images typically found on the web. - progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s. -flexibility in file formats is usually a bad thing. look at tiff. personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.

trompetenaccoun 1mo ago
Disagree with the second point. For one, there are many parts of the world where bandwidth still is an issue, either due to lack of infrastructure or because common people in those places can't afford better connections. This isn't going to change any time soon because although given bandwidth goes up over time, so do the file sizes websites serve. And even then, I'm posting this through a super fast connection, with which I still occasionally experience loading issues when my VPN acts up, because I live in a place with extreme censorship - which is on the rise worldwide. Generally, the approach should always be to prioritize files loading as fast as possible.
- bawolff 1mo ago
  I agree there are exceptions on that point. Its just now its probably useful to like 5% of the average website's viewers, where 20 years ago it was useful to 95% of users.