I really wanted (and still want) JPEG-XL to succeed.
Not sure how feasible this is, but one thing that could of helped with .jxl is allowing it to be read by a jpeg decoder. Let me explain. JPEG-XL has a feature that allows you to pull out a fully compliant jpeg, if you could somehow send the entire .jxl payload, and the browser's jpeg decoder just decoded the jpeg part, I feel adoption would be significantly easier, because then there is very minimal risk to just serving JPEG-XL with or without browser support.
Edit: Changing jpeg decoders around the world is not the approach I'm suggesting, but rather a carefully done "byte hack". Put the JPEG at the head of the binary blob, and stop decoding when the JPEG ends. If JPEG decoders only stop at the end of the byte stream, then another approach would be required.
I’d make the case it is the opposite. One off-brand browser can hold up the industry’s migration for years.
The cost model of images is such that you only get the full benefits of a new compression system if it is so widely used you can abandon old formats. That’s because the cost of images includes storage, transfer, plus handling and processing costs. If you have to maintain a large number of different formats, say JPEG, WEBP, AVIF,and JPEG-XL it’s just awful.
I can’t really use a new format until Safari supports it on mobile and mac at the very least. My take up of WEBP was considerably delayed because Apple was slow to get it in Safari on older Intel macs (one of which i have.)
Votes and comments aren’t a measure of popularity or importance. They’re super easily skewed by specific communities deciding to hammer the reports or similar - often about things they don’t have technical understanding of.
Other examples would be when Libc++ announced adding bounds checking by default and a huge number of people (from HN and similar) came in to provide votes/+1s or comments with little actual technical feedback
"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally."
The specification of AVIF is also publicly available, while you would have to pay a little under $500 to purchase all five of the ISO/IEC 18181 specifications for JPEG-XL. Not a monumental cost, but something prohibitive for a hobbyist:
Patented and royalty-free are not distict, it depends on whether the owners of the patent have agreed to others using it royalty-free, which is the case here (for both AVIF and JPEG-XL, and both have Google owned patents I think) .
So they are technically correct but a little misleading.
Google did not create JPEG-XL. They answered a call by the independent JPEG standards org, as did others. The majority of the spec and ideas came from elsewhere, as did the reference code.
Next you'll tell us Microsoft made C++ because they have an employee on the standards board...
This is kind of an awkward issue for FSF, since the relevant parts of chrome are free software. You can fork chrome and keep the jpeg-xl implementation in and surf the web.
But that doesn't matter, because the source being free isn't the issue, it's the default in a complex ecosystem of websites responding to browsers supporting standards, which they judge by uptake of the pre-standardized versions, etc etc etc.
[+] [-] bick_nyers|3 years ago|reply
Not sure how feasible this is, but one thing that could of helped with .jxl is allowing it to be read by a jpeg decoder. Let me explain. JPEG-XL has a feature that allows you to pull out a fully compliant jpeg, if you could somehow send the entire .jxl payload, and the browser's jpeg decoder just decoded the jpeg part, I feel adoption would be significantly easier, because then there is very minimal risk to just serving JPEG-XL with or without browser support.
Edit: Changing jpeg decoders around the world is not the approach I'm suggesting, but rather a carefully done "byte hack". Put the JPEG at the head of the binary blob, and stop decoding when the JPEG ends. If JPEG decoders only stop at the end of the byte stream, then another approach would be required.
[+] [-] Jasper_|3 years ago|reply
[+] [-] PaulHoule|3 years ago|reply
The cost model of images is such that you only get the full benefits of a new compression system if it is so widely used you can abandon old formats. That’s because the cost of images includes storage, transfer, plus handling and processing costs. If you have to maintain a large number of different formats, say JPEG, WEBP, AVIF,and JPEG-XL it’s just awful.
I can’t really use a new format until Safari supports it on mobile and mac at the very least. My take up of WEBP was considerably delayed because Apple was slow to get it in Safari on older Intel macs (one of which i have.)
[+] [-] jerryX|3 years ago|reply
Firefox: 434 upvotes, 61 comments: https://connect.mozilla.org/t5/ideas/idb-p/ideas/status-key/...
Official support software list: https://en.wikipedia.org/wiki/JPEG_XL#Official_support
Comparison/benchmarks: https://cloudinary.com/blog/contemplating-codec-comparisons
Feature comparison: https://jpegxl.info/comparison.png
[+] [-] olliej|3 years ago|reply
Other examples would be when Libc++ announced adding bounds checking by default and a huge number of people (from HN and similar) came in to provide votes/+1s or comments with little actual technical feedback
[+] [-] netol|3 years ago|reply
I thought AVIF was royalty-free.
[+] [-] Jasper_|3 years ago|reply
https://www.iso.org/standard/77977.html?browse=tc https://www.iso.org/standard/81554.html?browse=tc https://www.iso.org/standard/80617.html?browse=tc https://www.iso.org/standard/80618.html?browse=tc https://www.iso.org/standard/80619.html?browse=tc
[+] [-] ZeroGravitas|3 years ago|reply
So they are technically correct but a little misleading.
[+] [-] overstay8930|3 years ago|reply
Can't believe how far FSF has fallen if they have to resort to straight up lying to people to get their message across.
[+] [-] SideQuark|3 years ago|reply
Next you'll tell us Microsoft made C++ because they have an employee on the standards board...
[+] [-] fyzix|3 years ago|reply
[+] [-] webmobdev|3 years ago|reply
[+] [-] scorpio241|3 years ago|reply
[+] [-] habitue|3 years ago|reply
But that doesn't matter, because the source being free isn't the issue, it's the default in a complex ecosystem of websites responding to browsers supporting standards, which they judge by uptake of the pre-standardized versions, etc etc etc.