Ce billet a pour objectif de présenter le format WebP, encore assez méconnu, et surtout l’usage que j’en fais et pourquoi j’ai choisi de l’utiliser. En espérant le faire découvrir et élargir votre palette de choix de format¹ 🙂

WebP, quésako ?

Le WebP, pour Web Picture, est un format ouvert développé par Google (ne fuyez pas en courant :p) dans le but de réduire le poids des images sur le web. Oui, ça se sent dans le nom 😀
C’est donc un format essentiellement destiné à la diffusion le web, mais il a aussi un intérêt pour le stockage, avec un rapport de qualité d’image/poids du fichier intéressant face aux 3 formats les plus classiques, j’ai nommé le JPEG, le PNG et le GIF (et tout ça, dans un seul format). J’y reviendrai plus loin.

Support du format

C’est bien beau de trouver un « nouveau » format plus performant que les autres, encore faut-il pouvoir l’utiliser et qu’il se répande suffisamment pour qu’il soit pérenne. Et des formats alternatifs, même plus performants que le WebP, il y en a pléthore, mais souvent ils ne sont supportés nulle part.
Par chance, le WebP est plutôt bien supporté, même si le décollage a été long (il date de 2011, mais n’existe réellement que depuis 1 ou 2 ans).
En pratique il est encore parfois nécessaire de fournir une alternative (jpg/png) pour la diffusion, mais rarement pendant le processus de création/traitement de l’image.

Selon les systèmes d’exploitations

• Linux : bon support depuis plusieurs années, les explorateurs de fichiers affichent des miniatures sans problèmes, les lecteurs d’images aussi (et souvent l’export est proposé).
• Windows 10 : il est possible d’ouvrir avec le lecteur d’image par défaut, avec une extension du Windows Store. Idem pour Windows 8.
• Mac OS: l’aperçu des miniatures ne fonctionne pas dans Finder. Un outil peut s’installer pour corriger cela.
• iOS : sauf erreur il n’est pas supporté, pour la même raison que pour Safari.
• Android: le support est natif depuis des années (format créé par Google oblige), pour la lecture et souvent l’enregistrement des images (photos comprises).

Selon les navigateurs web

C’est le nerfs de la guerre pour ce format qui vise le web avant tout.
Et bien les fichiers sont lisibles dans tous les navigateurs web standards depuis pratiquement 2 ans (et pour certains bien plus).
Tous ? Non pas exactement, un certain irréductible Safari² résiste encore et toujours aux standards, parce que… Apple et les standards ¯\_(ツ)_/¯. Oui, tous, maintenant que Safari a rejoint les autres². Enfin, on te voit Internet Explorer au fond de la salle, mais soyons sérieux 🙂

² Source de l’information (qui sera plus à jour, si vous lisez ce billet longtemps après sa publication).

Dans les logiciels d’édition d’images

Je ne saurais être exhaustif sur ce point, mais côté libre, GIMP comme Krita et Darktable gèrent le WebP, ainsi que des logiciels moins utilisés comme les utilitaires fournis dans les distributions Linux (par exemple Gwenview et Showfoto).
Par contre, l’écriture et la lecture des données EXIF semblent ne pas (encore) être systématiquement supportées. Ça peut être un manque important.

Contexte d’utilisation

Je vais ici décrire mon usage du format, usage qui conditionne l’intérêt qu’on peut lui porter.

L’objectif principal pour moi est de réduire la place de ma bibliothèque de photos, et marginalement de limiter la quantité de données à transférer par Internet. Je gère toutes mes photos depuis Linux, avec les utilitaires de KDE (Dolphin et Gwenview en particulier) et Darktable pour le traitement des RAW. L’usage principal est donc l’export des RAW en WebP et la visualisation des images, secondairement la conversion de jpeg et png.
Quand je diffuse une image (sur internet ou autre), je reconverti en jpeg/png.

NB: Actuellement les WebP que j’exporte de Darktable, Showfoto ou Gwenview n’ont pas de métadonnées EXIFS. Je ne sais pas si c’est un problème des librairies utilisées pour l’enregistrement, ou pour la lecture des métadonnées. Personnellement cela ne me pose pas de vrai problème car je les ai toujours dans les RAW (que je conserve).

Pourquoi je l’utilise ?

Parce qu’il économise beaucoup de place !

J’ai observé une réduction d’environ 30% du poids des images à qualité constante par rapport aux JPG. Et souvent on peut baisser plus fort la qualité (comparé au jpeg) sans différence visuelle perceptible. Personnellement mon but est surtout de convertir des fichiers rapidement, tant pis pour les 5 ou 10% de différence si cela m’évite d’y passer beaucoup de temps: je ne fais pas du cas par cas pour optimiser au maximum, j’exporte dans la même qualité que j’aurais utilisé pour le jpeg, et je converti les jpeg avec la qualité d’origine ou de 5 à 10% de moins.
Bonus : pour les images en noir&blanc, le gain approche 50% !

Pour les PNG, j’observe une réduction de >35% du poids.
Il m’arrive aussi assez souvent de convertir un panorama en PNG (généré via Hugin) en WebP avec pertes (en qualité 80~90), sans différence visuelle visible à 100% de zoom, mais avec un gain de 70-90% du poids. L’usage n’est certes pas le même (format avec et sans pertes) mais personnellement cela me convient d’autant plus que je garde les fichiers utilisés pour générer le panorama, donc que le PNG ne m’est pas utile.

Pour les GIF, je ne sais pas, je n’en ai pas l’usage. Comme le WebP est basé sur un même algorithme qu’un certain codec vidéo, et que les formats vidéos sont souvent plus performants que le GIF, on peut s’attendre à des améliorations.

Résultat : un gain de >30% de poids sur une bibliothèque de photo, ça fait rapidement plaisir 🙂
Que ce soit à l’export des photos ou en convertissant des jpeg existant.

Je déconseille par contre de convertir sur des jpeg déjà très compressés (car la nouvelle compression implique des pertes d’informations supplémentaires), ou de le faire pour de l’archivage et pour ensuite reconvertir en jpg au moment de publier l’image (2 compressions supplémentaires -> double perte d’info).

Parce que la qualité d’image est meilleure qu’en JPG

Les effets d’artefacts quand la compression d’un jpeg est trop forte (ou qu’il y eu trop de compressions successives) sont bien connus. En comparaison, le WebP ne produit pas d’artefact, mais « floute » l’image. Le résultat est plus homogène que sur un jpeg, avec un rendu un peu plus lissé mais sans artefact disgracieux. Et pour de faibles compressions ce n’est perceptible qu’à 100%.
En pratique le résultat est beaucoup plus fidèle à l’image originale.

À qualité constante la différence reste faible, par contre à poids constant, c’est flagrant.

Conclusion

Si le WebP est pour moi un format mature et systématiquement bien plus intéressant que les JPG/PNG/GIF (qu’il peut remplacer à lui tout seul), son support reste encore un peu trop limité pour qu’il vienne vraiment les remplacer pour n’importe quel usage.
Par contre il est très intéressant à utiliser pour l’archivage de photographies &co, à partir du moment où nos logiciels favoris le supportent.
Pour le Web, il est très intéressant pour réduire le poids des pages, mais il est nécessaire d’avoir une alternative disponible pour les appareils ne supportant pas ce format (iOS/MacOS et ordinateurs anciens). Des outils existent déjà pour automatiser cela. Ce qui veut dire que le stockage sur le serveur est augmenté.

---

¹ Je ne dis et ne crois pas que le WebP soit LE format qui détrônera l’indétrônable JPEG et ses copains PNG et GIF – et ce malgré toutes ses qualités. Je pense que ce format a un certain avenir comme un des standards alternatifs au trio de tête, sans les supplanter mais tout en restant disponible. En particulier sur Internet où il est déjà bien supporté.

² Et également Firefox sous iOS, parce qu’il est obligé d’utiliser le même moteur de rendu que Safari, parce qu’Apple interdit d’en utiliser un autre sur son système. Et ce moteur de rendu ne supporte pas le WebP.