Algorithme de compression des photos de Flickr : mon enquète

De plus en plus geek, je suis allé jusqu’à me demander comment Flickr faisait pour avoir une compression des images si belle et si peu destructive, sans pour autant donner des images trop lourdes.

J’ai donc décider, par des essais successifs, de tenter d’approcher l’algorithme sur l’outil de compression du logiciel libre The GIMP.

Pour cela, j’ai pris trois photos différentes de taille originale 1600×1200. La première photo, celle du mouton, faisait à l’origine 730 370 octets (en sortie d’appareil photo), la seconde, celle de la Renault Laguna Coupé faisait 680 839 octets et la troisième, celle de l’avion avec le pic du Canigou en fond, 424 896 octets.

Pour mieux vous mettre dans le bain, voilà les photos en question :

Photo Test 1

Photo Test 2

Photo Test 3

Une fois envoyées sur Flickr, j’ai retéléchargé ces photos dans leur taille originale, puis ais à nouveau regardé leur taille. Bilant : les photos faisaient toujours exactement le même poids. On peut donc considérer qu’elles n’ont pas été compressées, et donc que c’est vraiment la photo originale qui est restituée quand on demande la taille maximale pour la photo.

Maintenant, ne me restait plus qu’à faire le même test pour la taille « large » (1024×768 pixels). Pour cette taille, Flickr avait forcément compressé chaque photo. Après téléchargement, je constatait que la photo 1 faisait 565 343 octets, la photo 2 faisait 509 244 octets et la photo 3 : 327 013 octets.

Ne me restait donc plus qu’à effectuer moi-même des redimensionnements de mon côté pour cette taille (1024×768 pixels pour mémoire), et à voir quelle quantité d’octets faisaient les même images chez moi.

Voilà la série de tests que j’ai effectué :

Photo 1 :

  • Interpolation cubique (ou linéaire), qualité 98%, compression progressive et optimisée : 520 750 octets.
  • Interpolation cubique (ou linéaire), qualité 98%, compression optimisée : 557 079 octets.
  • Interpolation cubique (ou linéaire), qualité 98% : 582 323 octets.
  • Interpolation Sinc (Lanczos3), qualité 98%, compression progressive et optimisée : 570 684 octets.
  • Interpolation Sinc (Lanczos3), qualité 98%, compression optimisée : 609 102 octets.
  • Interpolation Sinc (Lanczos3), qualité 98% : 637 425 octets.
  • Pas d’interpolation, qualité 98%, compression progressive et optimisée : 583 706 octets.
  • Pas d’interpolation, qualité 98%, compression optimisée : 622 857 octets.
  • Pas d’interpolation, qualité 98% : 650 786 octets.
  • Pas d’interpolation, qualité 97% : 567 462 octets.

Sur la photo 1 (qui chez Flickr faisait 565 343 octets), pour l’interpolation utilisée lors du redimensionnement, qu’elle soit Linéaire ou Cubique, j’obtenais les même résultats. Avec l’interpolation Sinc comme sans interpolation, les résultats étaient supérieur en quantité d’information. Le résultat le plus probant fus sans aucun doute celui qui fut fait sans interpolation durant le redimmensionnement, et sans compression particulière.

Photo 2 :

  • Interpolation cubique (ou linéaire), qualité 98%, compression progressive et optimisée : 471 255 octets.
  • Interpolation cubique (ou linéaire), qualité 98%, compression optimisée : 498 042 octets.
  • Interpolation cubique (ou linéaire), qualité 98% : 510 870 octets.
  • Interpolation Sinc (Lanczos3), qualité 98%, compression progressive et optimisée : 525 468 octets.
  • Interpolation Sinc (Lanczos3), qualité 98%, compression optimisée : 552 646 octets.
  • Interpolation Sinc (Lanczos3), qualité 98% : 569 465 octets.
  • Pas d’interpolation, qualité 98%, compression progressive et optimisée : 544 820 octets.
  • Pas d’interpolation, qualité 98%, compression optimisée : 570 735 octets.
  • Pas d’interpolation, qualité 98% : 589 273 octets.

Pour la deuxième photo (qui chez Flickr fait 509 244 octets je le rappelle), les résultats sur après les redimensionnements par interpolation cubique ou linéaire restent les mêmes, et ceux après interpolation Sinc et sans interpolation sont toujours plus gros. Cette fois-ci, le résultat le plus proche de celui de Flickr est celui fait après redimensionnement par interpolation cubique, en qualité 98%, sans compression optimisée ni progressive.

Photo 3 :

  • Interpolation cubique (ou linéaire), qualité 98%, compression progressive et optimisée : 320 695 octets.
  • Interpolation cubique (ou linéaire), qualité 98%, compression optimisée : 336 026 octets.
  • Interpolation cubique (ou linéaire), qualité 98% : 342 379 octets.
  • Interpolation Sinc (Lanczos3), qualité 98%, compression progressive et optimisée : 356 909 octets.
  • Interpolation Sinc (Lanczos3), qualité 98%, compression optimisée : 374 723 octets.
  • Interpolation Sinc (Lanczos3), qualité 98% : 381 462 octets.
  • Pas d’interpolation, qualité 98%, compression progressive et optimisée : 361 817 octets.
  • Pas d’interpolation, qualité 98%, compression optimisée : 380 006 octets.
  • Pas d’interpolation, qualité 98% : 386 747 octets.

Enfin, la troisième photo, qui faisait 327 013 octets après redimensionnement Flickr, a montré des résultats similaires aux deux photos précédentes.Pour elle, le résultat le plus approchant fut celui du redimensionnement par interpolation cubique, en qualité 98%, avec compression progressive et optimisée.

Conclusion :

J’aurais eu beau faire 12 tests par photo, soit 36 en tout, je ne pourais pas dire grand chose de précis à l’arrivée, à part que lorsque Flickr compresse les photos, il les enregistre avec un coefficient approchant les 98%…

Si, par contre, quelqu’un s’y connait d’avantage en compression d’image, et qu’il a plus d’informations là-dessus, je serais heureux de les entendre ! Par avance, merci.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.