Notes de l'équipe sur l'artisanat, les formats et les petites décisions derrière un bon résultat.
Pourquoi le WebP n'est pas pris en charge partout dans les logiciels de bureau
WebP est sorti chez Google en 2010, mais son adoption par les logiciels de bureau a traîné loin derrière celle des navigateurs. Les navigateurs ont adopté le WebP tôt parce qu'ils maîtrisent leurs propres moteurs de rendu et que Google a poussé activement la prise en charge du WebP dans Chrome comme avantage concurrentiel. Les applications de bureau avancent plus lentement sur un nouveau format d'image, car chacune entretient sa propre pile de décodage et un nouveau format demande des tests face à une longue série de cas particuliers. Adobe Photoshop, l'outil quotidien de la plupart des photographes et designers professionnels, n'a livré la prise en charge native du WebP qu'avec la version 23.2, fin 2022. Les applications Microsoft Office traitent le WebP de façon inégale selon les plateformes encore en 2026. Les logiciels de RIP d'impression et la majorité des vieux outils d'archivage ne l'ont jamais adopté. En pratique, un fichier parfait dans le navigateur peut être refusé par le logiciel qu'utilise l'utilisateur. Convertir en PNG est le contournement fiable.
Comment le WebP obtient son avantage de compression sur le PNG
Sous le PNG se trouve DEFLATE, un cheval de trait sans perte qui date de 1996. déo et l'apprentissage automatique qui ont affiné le métier. Le WebP apporte deux astuces plus récentes. En mode avec perte, il tire une transformée par blocs de la vidéo VP8, avec prédiction intra-image et transformée en cosinus discrète sur des macroblocs de 16x16. En mode sans perte, il tisse une prédiction spatiale avec une transformée de couleur et une étape LZ77 qui empaquette les données d'image typiques plus serré que DEFLATE n'y parvient. Les données de Google placent le WebP sans perte environ 26% sous le PNG sur un jeu d'images standard. Le WebP avec perte et alpha est environ trois fois plus petit à qualité visible égale. Aller de PNG à WebP encaisse ce gain, donc aller de WebP vers PNG le restitue, et le fichier enfle.
Exemples mesurés de croissance de la taille
Ces chiffres viennent de Chrome 148 sur un bureau Linux, avec le chemin d'écriture PNG de la plateforme appliqué à des entrées WebP décodées par le navigateur. Prenez un petit graphisme de style vectoriel en 400x300 pixels enregistré en WebP qualité 80, il se réécrit en PNG en 15 à 25 ms environ avec une croissance d'un cinquième à un tiers. Un WebP photographique en 1024x768, disons petite taille, se réécrit en PNG en moins de 100 ms et gonfle de trois à cinq fois. Passez à un gros WebP photographique en 3840x2160, grande taille, et le PNG prend à peu près 1,2 seconde à écrire en grossissant de cinq à dix fois selon la richesse de la scène. À l'extrémité, une grande photo WebP peut atterrir près de un PNG bien plus lourd. Chaque chiffre reflète à quel point le WebP empaquette plus serré les mêmes pixels, et la croissance suit le nombre de pixels.
La transparence alpha sur l'aller-retour
Le canal alpha 8 bits du WebP et du PNG utilise la même plage de valeurs, où 0 signifie totalement transparent et 255 totalement opaque. Quand le navigateur décode un WebP porteur d'alpha, il construit un tampon de pixels en valeurs RGBA dont la composante A reflète l'alpha d'origine. Réécrire ce tampon en PNG inscrit ces valeurs A directement dans le canal alpha propre du PNG. Aucune composition n'a lieu, aucune couleur de fond n'est posée et aucune prémultiplication ne décale en silence les pixels. Le résultat est une remise sans perte de l'alpha, où l'opacité de chaque pixel dans le PNG égale ce que le WebP tenait. Sur des images au lissage fin des bords, chaque valeur intermédiaire traverse le trajet entière, disons un pixel à 40 pour cent d'opacité le long du bord d'une lettre. Cette fidélité fait pencher le choix vers PNG plutôt que JPG dès que l'application réceptrice doit afficher l'image sur plus d'un fond.
Comportement de l'EXIF et des métadonnées
La réécriture efface les champs EXIF, IPTC et XMP du PNG produit. Un WebP peut loger de l'EXIF dans son bloc de métadonnées, et ce bloc disparaît dès que le navigateur décode et réécrit le fichier. Les profils colorimétriques suivent leur propre chemin. Chrome et Safari conservent l'étiquette de profil sRGB sur le PNG après lecture du WebP, alors que Firefox balaie tout, le profil ICC compris. Cela laisse une sortie que chaque navigateur lit comme sûre en sRGB, mais un profil à large gamut caché dans le WebP source ne passe pas par Firefox. Si votre chaîne photo vit sur des aller-retours étiquetés ICC, choisissez un convertisseur qui soigne les métadonnées exprès. Pour du travail web ordinaire, perdre ces champs est en général bienvenu et rogne en plus un peu la taille du fichier.
Vérifier la confidentialité en pratique
Vous éprouvez l'affirmation qu'aucune donnée du fichier ne quitte le navigateur avec le seul navigateur. Ouvrez-le, allez sur la page webp-to-png, puis appelez les outils de développement avec F12 ou le menu clic droit. Basculez sur l'onglet Réseau, videz ce qui est listé et lancez une conversion en déposant un WebP. Filtrez sur Fetch, XHR ou All. Rien portant des données d'image n'apparaît pendant l'écriture. Les seules requêtes sur la page sont les ressources de chargement initial et de simples pings analytiques, qui journalisent seulement les vues de page et les Core Web Vitals, jamais votre image. Chaque grand convertisseur WebP vers PNG distant déclenche au moins un POST d'envoi et un GET de téléchargement par tâche, chacun écrit dans un journal serveur. Sur l'appareil, aucune de ces lignes n'est jamais créée, et c'est la différence qui compte quand le fichier porte quelque chose de privé.
