Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF?
(Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).
(Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).
https://www.slideshare.net/cloudinarymarketing/imagecon-2019...
Huh? It's obviously easier to ignore the spinner than to ignore a low-res image. You've seen the spinner before.
I know it's a small thing and doesn't really matter, but I don't like progressive photos.
Edit: This is just one context. There are plenty of other contexts where progressive is very useful.
and again.
oh, and again.
and-
When it's the background for some webpage, or some other photo I'm not focused on, the progressive quality is probably a good thing.
See, this is the issue. Progressive images aren't "mostly usable content"; they're vague, ugly blobs.
Plus I'd love the ability to say "I'm on a low bandwidth, $$$ per megabyte network, stop loading any image after the first iteration until I indicate I want to see the full one" because you almost never need full-progression-loaded images. They just make things pretty. Having rudimentary images is often good enough to get the experience of the full article.
(whether that's news, or a tutorial, or even an educational resource. Load the text and images, and as someone who understands the text I'm reading, I can decide whether or not I need the rest of that image data after everything's already typeset and presentable, instead of having a DOM constantly reflow because it's loading in more and more images)
And to enable this, the site only needed to create one high-resolution image.
Seems like a victory for loading speeds, for low-bandwidth, and for content creation.
I think FLIF looks incredible.
Well, it's not finalized as of yet (though it is imminent), so rate of adoption is just pure guesswork at this stage. However, things I deem necessary for a new image codec to become the next 'de facto' standard are:
royalty free
major improvements over the current de facto standards
Both AVIF and Jpeg XL tick these boxes, however Jpeg XL has another strong feature which is that it offers a lossless upgrade path for existing jpeg's with significantly improved compression as a bonus.
This being a 'killer feature' of course relies on Jpeg XL being very competitive with AVIF in terms of lossy/lossless compression overall.
I don't think so, but I don't quite see the point unless you are thinking of using it as a way to archive jpeg's, but in that case there are programs specifically for that, like PackJPG, Lepton etc.
The same thing can be done with image data. For something like jpeg you can keep the coefficients but store them in a more compact form.
For what it's worth JPEG XL claims that it's 'reversible', but I'm not sure if that means you get your original jpeg back, byte for byte, or you get an equivalent jpeg back.
I don't think getting the same JPEG is the goal here but getting a JPEG that decodes to the same image data.
But it might be more hassle than it's worth it to create the code and algorithms to do so.
Btw, if memory serves right, Google Photos deliberately gives you back the same pixels but not the same JPEG codestream bits under some circumstances. That's too make it harder to exploit vulnerabilities with carefully crafted files.
There is also a mode that only preserves the JPEG image data.
If you can't produce the exact same original jpeg, then you can still have some issues during the global upgrade process -- eg your webserver database of image hashes for deduplication has to be reconstructed.
A relatively minor problem to be sure, but afaict if jpegXL does support this (which apparently it does), the upgrade process is really as pain-free as I could imagine. I can't really think of anything more you could ask for out of a new format. Better & backwards+forward compatibility
>A lightweight lossless conversion process back to JPEG ensures compatibility with existing JPEG-only clients such as older generation phones and browsers. Thus it is easy to migrate to JPEG XL, because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients.