L’informatique Ă©volue, les techniques de compression s’amĂ©liorent, et il est trop facile de rester figĂ©s dans ses anciennes habitudes Donc j’ai voulu faire un petit comparatif de compressions d’images spĂ©cialisĂ©es photographies.
Image source:
Tommie Hansen (Creative Commons by)Pour cette image, j’ai fait une première compression JPEG (libjpeg-turbo) avec niveau de qualitĂ© faible mais toutes les optimisations disponibles: en sort une image de 320 ko, mon « mètre-Ă©talon », toutes les autres techniques de compression devront faire des images de poids Ă©gal ou infĂ©rieur.
Et puisque je ne peux pas envoyer un fichier PNG pour chaque compression (+ de 20 Mo Ă chaque fois), j’ai extrait une partie de l’image avec imagemagick: -crop 1200×700+3700+500 (cette zone correspond aux arbres en arrière plan Ă droite, une bonne cible car peu reprĂ©sentatifs de l’image mais tout de mĂŞme assez dĂ©taillĂ©s).
Voici donc le résultat libjpeg-turbo fait avec GIMP (cliquez pour avoir en taille réelle):
Pour remplacer JPEG, il y a eu 2 formats: JPEG-XR et JPEG2000. Globalement, ils se sont plantĂ©s: très faible adoption et des problèmes de brevets et tout. JPEG2000 est une compression wavelet tandis que JPEG-XR est un classique DCT. J’ai obtenu avec XnView, JPEG2000:
On remarque que la technique de compression wavelet a du sens pour les dĂ©gradĂ©s, mais des dĂ©tails sont complètement « lavĂ©s ».
JPEG-XR:
Un peu mieux, non ? Bon, passons aux choses sĂ©rieuses. Firefox ne sait pas (encore ?) dĂ©coder les images WebP, et il y a une raison Ă cela: Mozilla a estimĂ© que le WebP n’apporte qu’un faible gain de qualitĂ© par rapport Ă JPEG (je suis pas de cet avis), et pour le prouver ils dĂ©veloppent une nouvelle bibliothèque d’encodage JPEG, nommĂ©e MozJPEG. L’avantage est Ă©norme: il produit des images lisibles par tous les dĂ©codeurs JPEG disponibles. Donc pour tester cela, j’ai compilĂ© MozJPEG 3, qui vient en remplacement de libjpeg-turbo (donc GIMP peut l’utiliser). La compression est plus lente, mais on remarque tout de suite que le paramètre de qualitĂ© peut ĂŞtre tirĂ© vers le haut par rapport Ă libjpeg-turbo pour obtenir un poids Ă©quivalent. Voici donc ce que ça donne:
Visuellement, MozJPEG est meilleur que JPEG-XR. Bien jouĂ© ! Bah du coup je garde MozJPEG comme librairie d’encodage JPEG sur mon PC Mais ça reste qu’un « petit ».
Passons aux champions issus du monde de la vidĂ©o: WebP et BPG. Le premier utilise les techniques d’encodage du VP8 dĂ©veloppĂ© par Google, le second les techniques du H.265 et est crĂ©e par Fabrice Bellard. Oui, LE Fabrice Bellard.
La principale amélioration de ces formats de compression est leur filtre de deblocking. Visuellement, ça rend beaucoup mieux. Voici ce que ça donne en WebP via plugin GIMP:
Et maintenant, BPG via bpgenc:
C’est diablement difficile de les dĂ©partager. BPG parvient Ă un peu plus de dĂ©tails (cime des arbres, moins de « bavures », la mousse sur le rocher..) MAIS crĂ©e une sorte d’inconsistance de qualitĂ©, on arrive Ă distinguer des blocs dans les arbres. Si on observe la mer et les nuages, BPG s’arrache un lĂ©ger avantage de qualitĂ©.
Avec WebP et BPG dans un mouchoir de poche, la suite s’annonce intĂ©ressante. Car Google continue de foncer dans son format vidĂ©o, avec le VP9 dont j’espère de nettes optimisations de compression Ă la prochaine version stable de libvpx, alors que Google annonce dĂ©jĂ commencer Ă bosser sur VP10…  CĂ´tĂ© H.265, bah ça se tourne les pouces… j’ai fait quelques tests avec x265 par exemple, et bien on est encore loin de remplacer H.264 high 10bit.
BPG bien que prometteur pourrait ne rester qu’une « dĂ©mo technique », qui se heurterait aux cauchemars des brevets relatifs Ă JPEG, l’histoire du GIF, les clowneries du MPEG-LA avec H.264 et les horizons Ă peine Ă©claircis avec H.265.
Et puis je me dois de mentionner le projet Daala, supportĂ© par la fondation Xiph et Mozilla, qui pourrait Ă©galement introduire un format d’image hautement efficace en se dĂ©barrassant des contraintes de la compression DCT et de la lessiveuse wavelet pour des techniques inĂ©dites.