Kind of nice but considering half of the internet doesn’t accept AVIFs or WEBP I expect that it will take another decade until it’s really usable
AVIF is often unsupported, but in recent years, most sites seem to accept WebP. There was certainly a time in which most sites rejected WebP, and there are a handful of websites that still do have issues with it today, but it is certainly not “half the internet” at this point.
EDIT: Your main point is definitely true, though. It took several years to reach this level of WebP compatibility, and its still not perfect. JPEG XL compatibility adoption will unfortunately likely be just about as slow.
Will animated JPEG XL be supported? I like to make animated images and dislike GIF for obvious reasons, but WebP is not a perfect replacement for philosophical reasons. I am eager for more programs to support JPEG XL so I can use that format for the animations that I create.
But in my experience with WebP, some programs that claim to support that format only support static WebP images. When they encounter an animated WebP, some programs only render the first frame of that animation. Due to that experience, I am hesitant to assume that animated JPEG XL images will work just because static ones do.
If you want to test, here is an animated JPEG XL I made a while ago: https://files.catbox.moe/80ottu.jxl
It does seem to be animated when I view the file in firefox. That doesn’t have to mean it works when embedded on webpages though, but I guess there’s an easy way to test that :)
Do you have some experimental flag enabled or something? Neither link is working for me on LibreWolf.
Regardless, it is good to know that when Firefox supports JPEG XL, it seems to support animated ones.
EDIT: I just enabled that, and both of the above links work as expected!
1. Navigate toabout:config2. Searchjxl3. Toggleimage.jxl.enabledtotrueActually, see what @mschae@discuss.mschae23.de posted below. That is likely a safer method than messing with
about:configYes, there’s an “enable JXL (JPEG XL) support” toggle in the settings (tabs and browsing → media on librewolf (which is what I use too), or in ‘firefox labs’ on normal firefox).
Animated JXL worked for me on Firefox mobile after enabling that flag in about:config
It’s finally happening. Brings a tear to my eye.
I’ve been following the drama for years. This should’ve happened many years ago but for some reason Google was blocking it in favor of AVIF, which is worse in a number of ways.
Looking at the article it seems AVIF is better in almost every way except progressive rendering.
And lossless compression.
The killer feature is that JXL is better in that it can losslessly encode JPEG further, and the overwhelming majority of the legacy image files that people have are JPEG. That alone should justify its support, because there are a lot of files out in the world where the highest quality, closest to “original” quality file is stored in JPEG format. A format that allows for the further compression with zero loss of quality from those originals is really important.
And the other thing this article (and a lot of the discussion around JXL) chooses not to cover is how JXL is a good format outside of just web images. It’s not just looking to replace JPG/PNG/webp. It’s also looking to replace raw photography formats like DNG, TIFF, and other formats that are used for full workflows from image capture from the imaging sensor itself, from cameras to scanners to medical imaging.
If JXL succeeds at becoming the dominant raw capture format, the entire workflow of processing those raw images into exported web-friendly images will favor JXL for photography.
[…] today we posted our intent to ship JPEG XL. Chrome are also intending to ship, and given there’s already a partial implementation in Safari, the format will be supported across browsers before the end of the year.
Hoping for the best 🙏
Progressive rendering
This is really interesting. Now I wonder: would it be possible to use the same image for thumbnail and full view and instead control its display by maximum allowed transfer percentage? For example, by default, for thumbnails, all images on page are served only up to 15% of their full size, and when you click on them, the same image resumes downloading to 100% size. I mean, it’s definitely possible to implement this, but it would be nice to see this widely supported without getting too hacky.
For anyone interested you can enable that feature now. It’s just not enabled by default yet in Firefox
I’m not too familiar with this. Is the JPEG-XL already adopted by other browsers (read: Chome)?
Not by default, but it can be enabled with
chrome://flags/#enable-jxl-image-format. More on support here.Apple’s Safari supports still images in JXL.
Perhaps more notably, Apple’s iPhone ProRaw supports JXL encoding for its raw sensor data. They’re laying the groundwork for JXL to be a supported format from the point of capture at the camera, through all the processing to make an image for web publishing or whatever.
It’s on by default in Waterfox
YES! finally!
What is the big gain over AVIF?
It’s great at lossless? but I never use lossless for web images
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?
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.
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.
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.
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.
- “lossless” reencoding of jpeg
- 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.
- 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.
Jxl lossless can sometimes produce smaller images than even lossy compression, so it makes sense to use it when it does.
