Depuis quelques jours, un projet open source fait parler de lui dans le domaine de la (dé)compression d'images : le format QOI, présenté comme très rapide et sans perte. De quoi inciter certains développeurs à l'implémenter dans différents langages. Mais en pratique, il vaut quoi ?
Fin novembre, Dominic Szablewski présentait un projet de format de (dé)compression d'images sans perte aux objectifs simples : un code léger (300 lignes de C), efficace, n'exploitant qu'un thread, n'effectuant qu'une seule passe, sans SIMD. « QOI ne touche chaque pixel qu'une seule fois, ils sont encodés d'une parmi quatre manières ».
Le résultat est présenté comme 20x à 50x plus rapide que des bibliothèques comme libpng ou stb pour la compression, 3x à 4x en décompression. Le tout avec une taille de fichier similaire. Le code source est disponible sous licence MIT, le développeur précisant que le projet n'est pas encore finalisé, bien que déjà fonctionnel.
D'autres sont d'ailleurs déjà nés de cette initiative, comme qoiview pour la visualisation d'images mais aussi des implémentations en C#, Elixir, Go, Python, Rust (1, 2, 3), Swift et même le nouveau langage à la mode : zig.
Téléchargement, compilation
Pour vérifier les chiffres annoncés par le développeur et le fonctionnement de QOI, nous avons lancé une machine virtuelle sous Debian (via Proxmox VE 7.1) avec 1 cœur de notre Xeon E-2388G et 1 Go de mémoire. L'installation était minimale, nous avons donc dû récupérer plusieurs applications pour télécharger et compiler le code source :
sudo apt update && sudo apt upgrade
sudo apt install build-essential curl git libpng++-dev
On récupère le code source de qoi et les images de test :
git clone https://github.com/phoboslab/qoi.git
curl -O https://phoboslab.org/files/qoibench/images.tar
On décompresse l'archive TAR contenant les images :
tar xf images.tar
On récupère les headers nécessaires pour l'utilisation de stb :
cd qoi
curl -LO https://github.com/nothings/stb/raw/master/stb_image.h
curl -LO https://github.com/nothings/stb/raw/master/stb_image_write.h
On compile les outils de mesure de performances et de conversion selon les recommandations du développeur :
gcc qoibench.c -std=gnu99 -lpng -O3 -o qoibench
gcc qoiconv.c -std=c99 -O3 -o qoiconv
Quels résultats ?
On peut alors lancer les tests avec 10 itérations sur chaque image que contient le dossier :
./qoibench 10 ../images/wallpaper/
Cela nous a donné les performances suivantes en moyenne :
decode ms encode ms decode mpps encode mpps size kb
libpng: 115.5 1619.0 81.15 5.79 9224
stbi: 122.7 1041.6 76.40 9.00 13299
qoi: 47.2 53.7 198.61 174.46 10640
On relève bien des écarts de 20x à 30x pour la compression et une division par un peu plus de deux pour la décompression. Le tout avec des fichiers légèrement plus gros par rapport à libpng, plus légers que via stbi. Ce qui est annoncé se vérifie donc bien en pratique. Mais comment vérifier que l'opération est bien sans perte ?
Taille des fichiers, le compte n'y est pas toujours
Pour le savoir, nous avons pris l'un des fonds d'écran (PNG) pour le convertir via qoiconv au format QOI avant de faire le chemin inverse et de retrouver une image au format PNG :
./qoiconv ../images/wallpaper/Hy23XKX.png Hy23XKX.qoi
./qoiconv Hy23XKX.qoi Hy23XKX_new.png
Si tout s'est bien passé, les deux fichiers PNG doivent être identiques, au pixel près. Et c'est effectivement le cas, ce qui est plutôt une bonne nouvelle.
Il y a néanmoins un bémol : le PNG calculé depuis le QOI pèse 9,58 Mo contre 6,38 Mo pour le fichier originel. Si le QOI pèse 7,47 Mo, la conversion inverse se fait avec une inflation importante. Un point à perfectionner.
Mais l'essentiel semble là puisque l'on a bien un format sans perte, plus rapide à (dé)compresser que les solutions concurrentes. Il sera donc intéressant de voir s'il est utilisé pour des usages particuliers où la performance est importante, malgré le besoin d'une qualité d'image non dégradée. L'avenir nous le dira.
