Given these positive signals, we would welcome contributions
Poor Google doesn’t have the manpower to implement it. They can only accept contributions from volunteers.
Google is just a small indie company after all.
“we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance.”
yeah
I would be more excited about JPEG XL if it was backward compatible. Not looking forward to yet another image standard that requires OS and hardware upgrades simply so servers can save a few bytes.
How would a new format be backwards-compatible? At least JPEG-XL can losslessly compress standard jpg for a bit of space savings, and servers can choose to deliver the decompressed jpg to clients that don’t support JPEG-XL.
Also from Wikipedia:
Computationally efficient encoding and decoding without requiring specialized hardware: JPEG XL is about as fast to encode and decode as old JPEG using libjpeg-turbo
Being a JPEG superset, JXL provides efficient lossless recompression options for images in the traditional/legacy JPEG format that can represent JPEG data in a more space-efficient way (~20% size reduction due to the better entropy coder) and can easily be reversed, e.g. on the fly. Wrapped inside a JPEG XL file/stream, it can be combined with additional elements, e.g. an alpha channel.
All you have to do is add a small traditional JPEG image at the start of the file. It doesn’t have to be high resolution or more than a couple of kb. The new format decoder would know this, and skip the traditional jpeg “header”, rendering the newer file format embedded in the image.
Would completely defeat the purpose of making a new smaller file format if we prefix if with the old format.
That would have been a brilliant move with wav vs MP3
