Tag: Image
JPEG XL vs AVIF: A Comparison
An unscientific analysis of these two image formats based on file size and image quality.
Edit (2023-03-30): Added a couple extra images to test for high-quality encoding and illustrations. Introduce SSIM and MSE measures.
Edit (2023-03-03): Fixed mistake, as AVIF does in fact NOT support progressive decoding.
Edit (2024-01-24): Following a comment on Mastodon, I have added a reference on the good performance of lossless WebP.
Disclaimer
This is a subjective look at JPEG XL and AVIF. All comparisons in this post (except the ones using SSIM and MSE) are perceptual and based on my own opinion only. This is not a scientific study! I just grabbed a bunch of images, encoded them and looked at the results. For a more careful and methodical comparison between these formats (and more), have a look at CID22.
JPEG XL and AVIF are arguably the two main contenders in the battle to replace JPEG as the next-generation image format. There are other formats in the race, like HEIC and WebP 2, but the former is subject to licensing patents (and possibly not royalty-free), and the second is still in development and seems that it may never see the light of day as a production-ready image format anyway. The original WebP is not even a contender as it is inferior to AVIF in almost all aspects1 (although it may be ok in lossless compression2), and you should probably never use it for photography anyway3, or at all if you are not ok with mediocre image quality.4
First, a quick browser support test:
If you are browsing this page around 2023, chances are that your browser supports AVIF but does not support JPEG XL. This is mainly due to the Chrome team dropping support for JPEGL XL against the opinion the community at large. In this post, I hope to convince you why this is a bad move. Below, I perform a quick analysis of lossless and lossy compression with JPEG XL and AVIF, and evaluate how they fare in terms of file size and visual quality.
Libvips Is a Good Image Processor
Libvips' resource usage and speed are unmatched, especially compared to ImageMagick.
Edit (2023-04-05): Added some suggestions by the author/developer of libvips.
Today I discovered libvips, a command line utility and library to manipulate and process images, and I am impressed. I’ve been using ImageMagick and its fork, GraphicsMagick, for as long as I have had to process images from the CLI, and they work well for moderately-sized images. But lately, I have been preparing virtual texture datasets for Gaia Sky and the sizes of my images have increased exponentially. Right now I’m processing 64K and 128K images on the regular (that is 131072x65536 pixels), and ImageMagick just can’t do it reliably. It uses so much memory that it can’t even split a 64K image in a 32 GB RAM machine without running out of it. Running it with the suggested options to limit memory usage (--limit memory xx mb
, etc.) and use a disk cache never works for me. It just produces blank images for some reason. So after implementing a couple of Python scripts based on OpenCV and NumPy to do some basic cropping, I took on the task of finding a proper, capable replacement. And found it I did. Libvips is the perfect tool, it seems. Based on my few first tests, it performs much better than ImageMagick and GraphicsMagick. It is super fast and never seems to use much memory, no matter how big an image I throw at it.
Google Kills JPEG XL
Why Google controlling Chrome/Blink development is bad for everyone
The web is currently based around the JPEG, PNG and GIF image formats. These are all very old and suboptimal formats which were never designed in the first place with the modern web in mind. A few newer competing formats have popped up recently, aiming to dethrone the original trio to postulate themselves as the standard web image format of the future. These are, essentially, WebP (.webp
extension), developed by Google and hated by almost everyone else, AVIF (.avif
extension), based on the AV1 container and developed by the ‘Alliance for Open Media’, a conglomerate of big tech companies that are anything but open, and JPEG XL (.jxl
extension), developed by the Joint Photographic Experts Group, the same people that developed the original JPEG.
So what’s the fuss all about? Recently, Google decided to kill JPEG XL support in Chrome. A full report follows.