the big win is that it can re-encode existing jpegs to shrink them by like 30%. also the image is compressed spatially (i think that’s the word) so it can be displayed as it’s downloading rather than coming in line by line.

I think many of us have several GBs of JPEGs that have accumulated over the years. It would be nice to shrink them a bit.

However I wouldn’t do it until the majority of my software supports it. At least with JXL, you can transcode it back to legacy jpeg without losing quality

The biggest hurdle are messengers, especially including cross-platform support and mobile devices.

Does the lossless transcode work both ways? Thought it was only jpg -> jxl

There seems to be a “JPEG reconstruction” feature that gets the original JPEG back.

But if you’re going through the trouble of re-encoding you might as well re-encode to AVIF, no?

jxl can also extract the original jpeg bit-for-bit, meaning you can save space on disk and still serve exactly the same images as some clients expect. no rewrites.

Re-encoding from JPEG to AVIF will always drop quality. Lossless re-encoding from JPEG to JPEG XL makes a pixel perfect reproduction, while shrinking file size.

1. “lossless” reencoding of jpeg
2. Encoding with “butteraugli distance =1” ensures that you compress optimally without the human eye being able to see the difference, it’s an awesome “fire and forget” setting for all your images besides lossless. You basically don’t have to guess or check your saved image if it looks good enough.
3. Unlimited size, multiple layers, better colors, more bit depth. Avif has severe limitations as an image format.

But for specific cases like comics and stronger compression at about 60% quality it’s currently better. I’ve heard jpegXL encoders still have some ways to improve though. For stronger compression avif can use “ssimulacra2” which is a great metric to avoid compression artifacts for encoders. So ideally jpegXL would support both butteraugly (high quality) and simulacra2 for low quality / high compression.

The argument for it is only lossless and progressive rendering. So if you have large files, it might be better to serve it as JXL, so it can show the image at least in some quality before it fully loads (for slow connections). If you have lossless files, then it's better also.

AVIF is better otherwise, so we will probably see AVIF become the new web image standard and JXL have a niche for higher quality images.

If JXL is good for lossless, it’ll probably AVIF replacing JPEG and JXL replacing PNG.

Yup, that makes sense! It's about time we replaced them.

Jxl lossless can sometimes produce smaller images than even lossy compression, so it makes sense to use it when it does.

As a browser-supported web image format, the only real runaway advantage of JXL is the ability to losslessly reencode existing JPEG files, when the vast majority of image files that people already have are stored as JPEG “originals.”

But as an overall image format, JXL has a much more ambitious scope: much higher limits in the spec to resolution, bit depth, layers, etc., showing an intent to be used as a raw image capture format and printing format, not limited to screen resolutions and bit depth like AVIF is.

So if the original file gets stored as JXL, the workflow and pipeline of a JXL native process the whole way may have an advantage over exporting to a screen-friendly AVIF at the end of the process, while the original still gets stored as another format.