Open veikk0 opened 1 year ago
This is planned for the future, but with the lack of current JPEG XL proliferation and tooling at the moment it's still on the shelf.
Hurray for Safari! https://caniuse.com/jpegxl How often does Apple lead with format support? Weird.
I'd probably press go on implementation once Pillow supports it: https://github.com/python-pillow/Pillow/issues/4247 But if browser support happens before that I'll bite the bullet and do my own format detection and metadata insertion.
A useful feature of JPEG XL is support for losslessly transcoding JPEG files into JPEG XL. This reduces file size by 20% on average, and the process is also reversible, so you can losslessly convert back to the original JPEG data.
JPEG XL also does "normal" lossless compression, so PNG files can be losslessly converted as well (about 35% size reduction, 50% for HDR).
The reference implementation is libjxl, and it's the best encoder so far. The conversion executable is
cjxl
, and the usage iscjxl INPUT OUTPUT [OPTIONS...]
. The effort/CPU time used for conversion is controlled with-e
. Higher numbers result in more processing time and higher compression efficiency. The default is 7, and if necessary, conversion can be made significantly faster with lower values. In my experience, libjxl is impressively fast.This might be a long-term feature request, but being able to convert to JPEG XL for lossless optimization would be useful. Even though JPEG XL support isn't universal yet, it's so much superior to the competition that it's only a matter of time. The codec is in it for the long haul and was designed as a long-term replacement for JPEG (which is now 30 years old) as well as PNG, unlike the WebM/AVIF style of web-centric codecs that want to introduce a new codec every few years if possible.
libjxl itself is easy to install, with static builds for Windows and Linux as well as .deb packages for Debian and Ubuntu available on the releases section. It's also available on Homebrew for MacOS.