undefined

points

[-]

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.

by encrypted_bird8 hours ago|

parent|

[-]

>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?

by farlight7 hours ago|

parent|

[-]

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

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)

by pxoe7 hours ago|

parent|

prev|

[-]

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.

by dchest7 hours ago|

parent|

prev|

[-]

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).

by shakna7 hours ago|

parent|

prev|

[-]

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.)

by bawolff5 hours ago|

prev|

[-]

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.

by trompetenaccoun2 hours ago|

parent|

[-]

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.

by bawolff1 hours ago|

parent|

[-]

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 mananaysiempre8 hours ago|

prev|

[-]

> [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.

by sb0577 hours ago|

parent|

[-]

Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.

by mananaysiempre6 hours ago|

parent|

[-]

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.

by danielheath8 hours ago|

prev|

[-]

One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( 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.