JPEG XL faces fierce competition from AVIF. And Google. A bit of bothUpdate about JPEG XL support and why it's a mixed bag: https://x.com/nixcraft/status/183...
Jpeg XL isn’t backwards compatible with existing JPEG renderers. If it was, it’d be a winner. We already have PNG and JPG and now we’ve got people using the annoying webP. Adding another format that requires new decoder support isn’t going to help.
Jpeg XL isn’t backwards compatible with existing JPEG renderers. If it was, it’d be a winner.
According to the video, and this article, JPEG XL is backwards compatible with JPEG.
But I’m not sure if that’s all that necessary. JPEG XL was designed to be a full, long term replacement to JPEG. Old JPEG’s compression is very lossy, while JPEG XL, with the same amount of computational power, speed, and size, outclasses it entirely. PNG is lossless, and thus is not comparable since the file size is so much larger.
JPEG XL, at least from what I’m seeing, does appear to be the best full replacement for JPEG (and it’s not like they can’t co-exist).
It’s only backwards compatible in that it can re-encode existing jpeg content into the newer format without any image loss. Existing browsers and apps can’t render jpegXL without adding a new decoder.
Legacy client support. Old devices running old browser code can’t support a new format without software updates, and that’s not always possible. Decoding jxl on a 15yo device that’s not upgradable isn’t good UX. Sure, you probably can work around that with slow JavaScript decoding for many but it’ll be slow and processor intensive. Imagine decoding jxl on a low power arm device or something like a Celeron from the early 2010s and you’ll get the idea, it will not be anywhere near as fast as good old jpeg.
Jpeg XL isn’t backwards compatible with existing JPEG renderers. If it was, it’d be a winner. We already have PNG and JPG and now we’ve got people using the annoying webP. Adding another format that requires new decoder support isn’t going to help.
“the annoying webp” AFAIK is the same problem as JPEG XL, apps just didn’t implement it.
It is supported in browsers, which is good, but not in third party apps. AVIF or whatever is going to have the same problem.
According to the video, and this article, JPEG XL is backwards compatible with JPEG.
But I’m not sure if that’s all that necessary. JPEG XL was designed to be a full, long term replacement to JPEG. Old JPEG’s compression is very lossy, while JPEG XL, with the same amount of computational power, speed, and size, outclasses it entirely. PNG is lossless, and thus is not comparable since the file size is so much larger.
JPEG XL, at least from what I’m seeing, does appear to be the best full replacement for JPEG (and it’s not like they can’t co-exist).
It’s only backwards compatible in that it can re-encode existing jpeg content into the newer format without any image loss. Existing browsers and apps can’t render jpegXL without adding a new decoder.
Why is that a negative?
Legacy client support. Old devices running old browser code can’t support a new format without software updates, and that’s not always possible. Decoding jxl on a 15yo device that’s not upgradable isn’t good UX. Sure, you probably can work around that with slow JavaScript decoding for many but it’ll be slow and processor intensive. Imagine decoding jxl on a low power arm device or something like a Celeron from the early 2010s and you’ll get the idea, it will not be anywhere near as fast as good old jpeg.
But how is that different to any other new format? Webp was no different?