WebP sans perte et exact (car tous les fichiers images ne codent pas rouge/vert/bleu/transparent)

Dérivé du format vidéo VP8, WebP est donc un format ouvert, qui permet de compresser de façon efficace avec ou sans perte, en RVB sur 24 bits, avec un canal alpha optionnel (à noter que ce dernier peut être compressé sans perte même pour une image compressée avec pertes). Il permet également de stocker des animations.

WebP est vraiment très efficace ! Pour des images à 8 bit par canal, si WebP est pris en charge, mieux vaut utiliser Webp que JPEG ou PNG, pour ces deux cas d’usage.

Exemple avec une texture de ciel étoilé du jeu Unvanquished (JPEG, WebP avec perte, PNG) :

comparaison Jpeg, PNG, WebP

Mais ! Chose importante à savoir pour ceux qui voudraient utiliser WebP ! Par défaut l’outil cwebp avec l’option -lossless ne produit pas d’image sans perte ! Ah bon ? Oui ! Si vous affichez une image, le rendu est exactement le même, pixel par pixel, couleur par couleur, MAIS, des données non visibles (pour un simple rendu) peuvent avoir été perdues. Pour faire un véritable WebP sans perte avec l’outil cwebp il faut utiliser les options -lossless -exact.

Mais qu’est ce que cette diablerie ? 😱️

Par défaut cwebp -lossless peut détruire des données si la transparence ne les rendraient pas visibles. Ça peut poser problème si on veut éditer une image... et changer la transparence. Ça peut aussi poser problème si on utilise WebP, pour autre chose que de la représentation de couleur et de transparence.

Comment ça les canaux rouge, vert, bleu, et transparence ne codent pas nécessairement les canaux rouge, vert, bleu et transparence ? 🤨️

Par exemple, dans les jeux vidéos, on va utiliser des formats d’image parce que c’est parfait pour représenter des matrices de données. Le premier image sera la texture, donc une « image » telle qu’on se l’imagine, mais on va aussi utiliser des formats d’images pour stocker d’autres données. Par exemple on va coder dans un « fichier image » additionnelle la façon dont lumière se réfléchit en telle ou telle partie de la texture : si c’est du béton, on va mettre une valeur pour dire que la surface ne brille pas beaucoup, si c’est du métal poli, on va mettre une valeur pour dire que la surface brille beaucoup. Ainsi dans le jeu, on va pouvoir afficher la couleur du béton et du métal, mais aussi appliquer sur ces couleurs des effets de reflets. Des « images » de ce type il en existe plein, pour coder la réflexion de chaque pixel, mais aussi des coordonnées de normale (X, Y, et Z dans R, V, B en général), ou l’élévation de texture (pour coder une illusion de déformation, pixel par pixel). Sauf que voilà, si on peut par exemple coder des coordonnées de normale X, Y, et Z dans R, V, et B, on peut aussi coder l’élévation dans le canal alpha, et alors, le canal alpha ne code pas de la transparence, et on ne peut supposer que les coordonnées X, Y, Z de la normale peuvent être ignorées parce que la profondeur est grande, ou encore, que la rugosité du pixel peut être ignorée parce que la métallicité du pixel est élevée ou que sais-je encore en fonction de telle ou telle convention de stockage. 🙃️ Il est donc possible de stocker plein de choses dans le canal alpha qui ne sont pas des informations de transparence, et plein d’autres choses dans les canaux R, V, B qui ne sont pas des couleurs, mais qui sont d’autres composantes du même pixel. 🧐️

Et donc, au final, puisque les images dans les jeux vidéos ont plus que quatre canaux (rouge, vert, bleu, transparence, addition de rouge, addition de vert, addition de bleu, normale X, normale Y, normale Z, élévation, rugosité, métallicité, occlusion, etc.), et que les formats d’images n’ont que 4 canaux, bah on doit stocker tous ces canaux pour une seule image dans plusieurs « fichiers images ». On peut donc se retrouver avec 2, 3, 4 fichiers images pour une seule image, mais un seul canal alpha utilisé pour coder de la transparence, et une collections de canaux RVB qui ne codent pas de la couleur. 🫣

Quand il n’y a pas besoin de format d’image sans perte dans un jeu vidéo, les jeux vidéos privilégient d’autres formats que le WebP ou le JPEG, comme les formats DXT qui sont transférés compressé dans la mémoire de la carte graphique, et stockés compressés dans la mémoire de la carte graphique. Mais dans un dépôt de source de données de jeu vidéo, on veut des format sans perte, donc si quelqu’un choisit de faire du WebP pour « giter » les images sources de son jeu libre, il devra utiliser cwebp -lossless -exact. Et s’il utilise PNG, ne pas oublier de cocher la case « Enregistrer les valeurs de couleur pour les pixels transparents » dans GIMP, pour la même raison.

D’ailleurs il faudra que je vérifie si GIMP propose la même option « Enregistrer les valeurs de couleur pour les pixels transparents » pour WebP. 😀️

ce commentaire est sous licence cc by 4 et précédentes