In this article, Jon Sneyers, who is one of the creators of JPEG XL, usually shortened JXL, compares it and other newer formats with PNG and JPEG. Some background on JXL, as it is much newer and...
In this article, Jon Sneyers, who is one of the creators of JPEG XL, usually shortened JXL, compares it and other newer formats with PNG and JPEG.
Some background on JXL, as it is much newer and less known than AVIF and the rest:
A few years ago, the JPEG Committee put out a call for proposals for a replacement for JPEG. The Google compression team in Zürich submitted their Pik format, which has a lot of similarities to JPEG on a technical level but is a lot more advanced, and Jon submitted his new FUIF format, which was based on his previous format FLIF. All other proposals were rejected, and Pik and FUIF were selected to serve as the basis of JPEG XL.
The biggest points for JXL are strong compression for high fidelity images, fairly high single thread speed combined with a high degree of parallelisation, and trying to not compromise in terms of features (JXL should be a superset of all functionality in GIF, PNG, JPEG, and TIFF).
JXL had its bitstream finalised about a month ago. As such, it has no adoption right now, though there are plugins for Windows and Qt allowing many applications to decode JXL.
Currently, Chrome has a priority 1 ticket to get JXL support going behind a flag, so that web developers, CDNs (such as Cloudinary), and users can start testing it more easily.
Edit: oh, and I should add, JPEG XL is royalty free. The reference implementation source code is available here under the Apache license.
In this article, Jon Sneyers, who is one of the creators of JPEG XL, usually shortened JXL, compares it and other newer formats with PNG and JPEG.
Some background on JXL, as it is much newer and less known than AVIF and the rest:
A few years ago, the JPEG Committee put out a call for proposals for a replacement for JPEG. The Google compression team in Zürich submitted their Pik format, which has a lot of similarities to JPEG on a technical level but is a lot more advanced, and Jon submitted his new FUIF format, which was based on his previous format FLIF. All other proposals were rejected, and Pik and FUIF were selected to serve as the basis of JPEG XL.
The biggest points for JXL are strong compression for high fidelity images, fairly high single thread speed combined with a high degree of parallelisation, and trying to not compromise in terms of features (JXL should be a superset of all functionality in GIF, PNG, JPEG, and TIFF).
JXL had its bitstream finalised about a month ago. As such, it has no adoption right now, though there are plugins for Windows and Qt allowing many applications to decode JXL.
Currently, Chrome has a priority 1 ticket to get JXL support going behind a flag, so that web developers, CDNs (such as Cloudinary), and users can start testing it more easily.
Edit: oh, and I should add, JPEG XL is royalty free. The reference implementation source code is available here under the Apache license.