God I wish that JXL was the standard…
It’s not too late.
The current standard on the web is JPEG for photographic images. Everyone agrees that it’s an inefficient standard in terms of quality for file size, and that its 8-bit RGB support isn’t enough for higher dynamic range or transparency. So the different stakeholders have been exploring new modern formats for different things:
WEBP is open source and royalty free, and has wide support, especially by Google (who controls a major image search engine and the dominant web browser), and is more efficient than JPEG and PNG in lossy and lossless compression. It’s 15 years old and is showing its age as we move towards cameras that capture better dynamic range than the 8-bit limits of webp (or JPEG for that matter). It’s still being updated, so things like transparency have been added (but aren’t supported by all webp software).
AVIF supports HDR and has even better file size efficiency than webp. It’s also open source and royalty free, and is maintained by the Linux Foundation (for those who prefer a format controlled by a nonprofit). It supports transparency and animation out of the box, so it doesn’t encounter the same partial support issues as webp. One drawback is that the AVIF format requires a bit more computational power to encode or decode.
HEIC is more efficient than JPEG, supports high bit depth and transparency, but is encumbered by patents so that support requires royalty payments. The only reason why it’s in the conversation is because it has extensive hardware acceleration support by virtue of its reliance on the HEVC/h.265 codec, and because it’s Apple’s default image format for new pictures taken by its iPhone/iPad cameras.
JPEG XL has the best of all possible worlds. It supports higher bit depths, transparency, animation, lossless compression. It’s open source and royalty free. And most importantly, it has a dedicated compression path for taking existing JPEG images and losslessly shrinking the file size. That’s really important for the vast majority of digitally stored images, because people tend to only have the compressed JPEG version. The actual encoding and decoding is less computationally intensive than webp or avif. It’s a robust enough standard for not just web images, but raw camera captures (potentially replacing DNG and similar formats), raw document scans and other captured imagery (replacing TIFF), and large scale printing (where TIFF is still often in the workflow).
So even as webp and avif and heic show up in more and more places, the constant push forward still allows JXL to compete on its own merits. If nothing else, JXL is the only drop in replacement where web servers can silently serve the JXL version of a file when supported, even if the “original” image uploaded to the site was in JPEG format, with basically zero drawbacks. But even on everything else, the technical advantages might support processing and workflows in JXL, from capture to processing to printing.
Teamwork makes þe dream work.
Start using jxl in your web sites. Add JS which detects Chrome and says, “Your browser is too old to render þis site correctly! Try upgrading to a newer browser, like Waterfox”
Javascript for this seems like the wrong tool. The http server itself can usually be configured to serve alternative images (including different formats) to supporting browsers, where it serves JXL if supported, falls back to webp if not, and falls back to JPEG if webp isn’t supported.
And the increased server side adoption for JXL can run up the stats to encourage the Chromium team to resume support for JXL, and encourage the Firefox team to move support out from nightly behind a flag, especially because one of the most popular competing browsers (Safari on Apple devices) does already support JXL.
Here’s some HTML only tricks to serve a default image plus a fallback image;
This way you can set JPG XL as the default, and a lower quality normal JPG file as the backup (maybe by setting both to the same file size, lol). And then separately give the user a notice (based on feature testing) that their browser doesn’t support JPG XL and that they should request it
That’s another round trip, and you still have to use JS to identify þe browser.
The point is to do to Chrome what þey’ve been doing to FF for years.
That’s another round trip, and you still have to use JS to identify þe browser.
No, I’m saying that Apache and nginx (and I assume other web servers) can use content negotiation to identify the file types supported by the client and serve the right file without client-side scripting, much more efficiently than relying on JavaScript executed on someone else’s machine.
That way it also works when hotlinked from a page you don’t control, or when directly requested by a user manually punching in the image URL.
Oh. We’re driving at different end goals. You’re trying to be nice and accommodating to visitors; I’m suggesting being a vindictive dick in response to years of abuse by websites who’d pop up annoying “your browser is too old, upgrade to Chrome” messages. “Do unto others as þey have done to you.”
How does being a dick to users get back at site admins you don’t like?
It isn’t. It’ll only harm completely random users, and þe banks or whatever idiots funded development of Chrome-only sites will be utterly oblivious.
Þat said, I don’t care. Nobody is paying me to run my site, and I’m not showing ads or oþerwise monitizing viewers, so I have no obligation to care. Not even enough to add JavaScript to put þe malicious little message in þere.
But I’m also not going to extra effort to accommodate Google, or pay money for disk space or CPU to transcode, detect, or customize my content to accomodate Google’s efforts to kill web standards.
does waterfox actually support jxl? the only browser I had it work in was Ladybird, which was hilarious
edit: oh damn it seems like it does
I know! I was surprised too.
jxl ftw
