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.
The brand new protocol is seeing a huge early adoption driven by discontent with established social networks
Updated:
5 minute read
After the acquisition of Twitter by the South African con-man and billionaire the free and open source social network world is generating a lot of heat. The number of users and nodes of Mastodon in particular and the Fediverse at large has been climbing steadily for months now. However, there is no shortage of people who voice their concerns about the federated nature of such services, which rely on centralized instances governed by small dictators with absolute power. But this is not the post to discuss these issues.
Just a short note. I have moved this site from Codeberg Pages to nearlyfreespeech.net. By the time you are reading this the move should already be finished. This hosting service is dirt-cheap for low-traffic static sites like mine. Right now, my estimated total sits at $0.31 per month, which is $3.72 per year. Less than the cheapest price per month offered by most other hosting providers. But they also only offer starting packages allocating many more resources than what is needed for simple static websites.
Libvips’ resource usage and speed are unmatched, especially compared to ImageMagick.
Updated:
3 minute read
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.
A technical description of my implementation of Sparse Virtual Textures in Gaia Sky
Updated:
20 minute read
Real time rendering of the Earth in Gaia Sky with surface, cloud and height virtual textures.
Implementing proper virtual texture support in Gaia Sky has been on my to-do list for many years. And for many years I have feared that very item, as the virtual texture mechanism is notoriously complex and hard to implement. However, once working, they are very cool and bring a lot of value to a Universe visualization platform such as Gaia Sky. In this post, I describe and discuss my implementation of virtual textures in Gaia Sky in detail, and provide a thorough examination of some of its most interesting points. If you are looking for the specifics of how to define or use virtual texture datasets in Gaia Sky, please refer to the official documentation. Here I provide only a general technical description.
Why Google controlling Chrome/Blink development is bad for everyone
Updated:
4 minute read
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.