La bibliothèque open source Jpegli de Google peut compresser des images de haute qualité 35 % de plus que les codecs JPEG traditionnels

Google a publié la bibliothèque open source Jpegli pour le codage JPEG avancé qui maintient la compatibilité ascendante tout en offrant une amélioration du taux de compression jusqu’à 35 % avec des paramètres de compression de haute qualité.

Google Research travaille depuis de nombreuses années à améliorer la compression des données (Brotli), de l’audio (par exemple Lyra V2) et des images avec un projet tel que WebP afin d’accélérer le Web et de le faire consommer moins de bande passante pour économiser de l’argent et réduction des émissions de carbone. Jpegli est leur dernier projet et vise à améliorer le taux de compression des fichiers JPEG existants sur les systèmes où la compression moderne telle que WebP n’est peut-être pas disponible ou souhaitable.

Points forts de Jpegli :

• Prend en charge à la fois un encodeur et un décodeur conformes à la norme JPEG d’origine (8 bits) et offrant une compatibilité API/ABI avec libjpeg-turbo et MozJPEG.
• Concentrez-vous sur des résultats de haute qualité avec un taux de compression jusqu’à 35 % supérieur.
• Aussi rapide que libjpeg-turbo et MozJPEG.
• Prise en charge du codage de plus de 10 bits. Google explique que les solutions de codage JPEG traditionnelles n’offrent qu’une dynamique de 8 bits par composant, provoquant des artefacts de bandes visibles dans des gradients lents, mais le codage 10+ bits de Jpegli contourne ce problème tout en restant compatible avec les visionneuses 8 bits. Bénéficier des bits supplémentaires nécessite des modifications de code disponibles via une API.

Jpegli fonctionne en utilisant des heuristiques de quantification adaptatives de l’implémentation de référence JPEG XL et une sélection de matrice de quantification améliorée pour respectivement réduire le bruit et améliorer la qualité de l’image ET optimiser (les données) pour un mélange de mesures de qualité psychovisuelle. Le blog open source de Google contient plus de détails sur les composants internes de la bibliothèque.

L’implémentation de l’encodeur et du décodeur Jpegli JPEG fait partie de l’implémentation de référence du format d’image JPEG XL (libjxl) et vous trouverez le code source sur GitHub. À terme, il pourrait être intégré à vos bibliothèques et programmes préférés, et vous pourrez installer le support Jpegli de JPEG XL à partir du package libjxl-tools dans votre distribution Linux préférée. Mais en attendant, nous pouvons utiliser les outils tools/cjpegli et tools/djpegli en construisant libjxl à partir des sources (testé dans Ubuntu 22.04) :

</p> <p>git clone https://github.com/libjxl/libjxl.git –recursive –shallow-submodules cd libjxl sudo apt install cmake pkg-config libbrotli-dev sudo apt install clang libstdc++-12-dev export CC=clang CXX= clang++ cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF .. cmake –build . — -j$(nproc)

Une fois la construction terminée, nous pouvons vérifier l’utilisation des utilitaires de décompression et de compression :

</p> <p>jaufranc@Raspberryme-LAPTOP-5:~/edev/sandbox/libjxl/build$ tools/djpegli Utilisation : tools/djpegli INPUT OUTPUT [OPTIONS…]<br /> INPUT Le fichier d’entrée JPG. OUTPUT La sortie peut être PNG, PFM ou PPM/PGM/PNM –disable_output Aucun fichier de sortie ne sera écrit (pour l’analyse comparative) –bitdegree=8|16 Définit la profondeur de bits de sortie pour les formats basés sur des nombres entiers, peut être 8 (par défaut) ou 16. N’a aucun impact sur la production de la GFP. –num_reps=N Définit le nombre de fois où décompresser l’image. Utilisé pour l’analyse comparative, la valeur par défaut est 1. –quiet Sortie Silence (sauf pour les erreurs). -h, –help Imprime ce message d’aide. Toutes les options sont affichées ci-dessus. jaufranc@Raspberryme-LAPTOP-5:~/edev/sandbox/libjxl/build$ tools/cjpegli Utilisation : tools/cjpegli INPUT OUTPUT [OPTIONS…]<br /> SAISIR l’entrée peut être PNG, APNG, GIF, EXR, PPM, PFM ou PGX SORTIR le fichier de sortie JPG compressé -d maxError, –distance=maxError Max. Distance butteraugli, inférieure = qualité supérieure. 1.0 = visuellement sans perte (par défaut). Plage recommandée : 0,5 .. 3,0. Plage autorisée : 0,0 … 25,0. Mutuellement exclusif avec –quality et –target_size. -q QUALITÉ, –quality=QUALITY Paramètre de qualité (est remappé en –distance). La qualité par défaut est 90. Les valeurs de qualité correspondent à peu près à la qualité libjpeg. Plage recommandée : 68 .. 96. Plage autorisée : 1 .. 100. Mutuellement exclusives avec –distance et –target_size. –chroma_subsampling=444|440|422|420 Paramètre de sous-échantillonnage Chroma. -p N, –progressive_level=N Réglage du niveau progressif. Plage : 0 .. 2. Par défaut : 2. Un nombre plus élevé correspond à plus de balayages, 0 signifie séquentiel. -v, –verbose Sortie verbeuse ; peut être répété, s’applique également à l’aide (!). -h, –help Imprime ce message d’aide. Ajoutez -v (jusqu’à 2 fois au total) pour voir plus d’options.

J’ai d’abord utilisé une capture d’écran PNG pour tester la compression :

</p> <p>jaufranc@Raspberryme-LAPTOP-5:~/edev/sandbox/libjxl/build/tools$ time ./cjpegli capture d’écran.png capture d’écran.jpg Lire l’image 1291×1132, 164009 octets. Codage [YUV d1.000 AQ p2 OPT]<br /> Compressé à 137 052 ​​octets (0,750 bpp). 1291 x 1132, 45,812 MP/s [45.81, 45.81], , 1 répétition, 1 fil. réel 0m0.057s utilisateur 0m0.044s sys 0m0.012s

Cela a fait l’affaire et j’ai pu ouvrir le fichier résultant avec la visionneuse d’images GNOME avec de très petites différences par rapport au fichier PNG en termes de qualité après zoom sur des zones spécifiques (texte), mais une taille de fichier plus petite :

</p> <p> ls -lh capture d’écran.* -rw-rw-r– 1 jaufranc jaufranc 134K 4 avril 17:49 capture d’écran.jpg -rw-rw-r– 1 jaufranc jaufranc 161K 4 avril 17:48 capture d’écran.png

La commande decompress fonctionne à peu près de la même manière :

</p> <p>$ time ./djpegli capture d’écran.jpg capture d’écran-decode.png Lit 137052 octets compressés. 1291 x 1132, 42,052 MP/s [42.05, 42.05], , 1 répétition, 1 fil. réel 0m0.097s utilisateur 0m0.078s sys 0m0.013s

Le fichier PNG résultant est beaucoup plus volumineux que l’original, mais c’est normal en raison de l’artefact créé par la compression JPEG :

</p> <p>$ ls -l capture d’écran* -rw-rw-r– 1 jaufranc jaufranc 330728 4 avril 18:06 capture d’écran-decode.png -rw-rw-r– 1 jaufranc jaufranc 137052 4 avril 17:49 capture d’écran.jpg -rw -rw-r– 1 jaufranc jaufranc 164009 4 avril 17:48 capture d’écran.png

Quoi qu’il en soit, il est facile d’essayer avec différents fichiers image et de comparer les résultats avec jpeg-turbo, MozJPEG ou des outils graphiques comme GIMP en veillant à utiliser les mêmes paramètres de compression.

Retrouvez l’histoire de Raspberry Pi dans cette vidéo :