Commentaires sur : La révolution fracassante et la révolution qui couve

Par : Frédéric Kayser

cryopng@free.fr — Sat, 11 Aug 2012 02:59:25 +0000

Je réagis ici à l'article de Karl. Effectivement JPEGmini et WebP n'évoluent pas sur le même plan, je les ai rassemblés dans un même article traitant des images car la disponibilité de l'application JPEGmini est assez récente et l'évolution de WebP pour se doter de la transparence et de la compression sans perte approche de sa conclusion, les deux méritaient je pense d'être mis en avant. J'ai volontairement évité la confrontation entre JPEG et WebP car comparer deux formats avec perte d'information c'est un peu comme s'engager sur un terrain miné bordé de snipers. Je me suis focalisé sur les nouveautés de WebP, car c'est probablement à ce niveau que son avenir se joue. WebP a le potentiel nécessaire pour remplacer PNG (tout du moins sur le Web) et comme l'indique Yoav Weiss dans son comparatif les PNG-32 sont souvent utilisés à défaut de mieux car il n'y pas de réelle alternative pour diffuser simplement sur le Web une image photo-réaliste avec de la transparence. En fait les alternatives existent : JNG, JPEG 2000 et JPEG XR. - JNG est un cousin du PNG (plus précisément du MNG) qui permet d'inclure une image (compressée JPEG) et une couche alpha (compressée PNG) dans un seul fichier. Il est peut-être arrivé un peu trop tôt, dès 2000, et est quasiment oublié aujourd'hui. - JPEG 2000, j'ai failli le mentionner sous la forme d'une boutade car en 2000 on trouvait plein d'articles pour dire plein de bien de ce format plein d'avenir et annoncer que l'année prochaine plein de fabricants d'appareils photo l'auraient adopté. On est en 2012, je vous laisse plein de temps pour vérifier sur vos APN qu'il n'y est pas. Les couacs au niveau licence (la "part 1", le format à l'état le plus simple, est désormais sensé être gratuite mais sans garantie quant à d'éventuels brevets cachés) ainsi que la complexité de sa compression et la lenteur que cela induit (8 fois plus lent que JPEG au début) pour un gain de place ou qualité assez maigre sur les photographies, sans oublier l'absence de bibliothèque libre pour supporter le format (OpenJPEG de nos jours) n'ont pas contribué à sa diffusion. Pour autant il y a vraiment plein de choses très bien dans JPEG 2000, comme les ROI (Regions Of Interest) qui permettent d'augmenter ou de sacrifier la qualité de certaines zones de l'image, la résolution évolutive (resolution scalability) à l'heure où l'on parle de « responsive design » il y a peut-être de quoi faire, ou encore une compression alternative sans perte d'information (un peu désavouée par JPEG-LS qui est bien plus rapide). Mac OS X intègre JPEG 2000 au niveau de Core Graphics (vu les commentaires dans les fichiers la bibliothèque provient de Kakadu Software), les icônes des applications Mac OS X sont du JPEG 2000 sans perte, Safari affiche du JPEG 2000 sans soucis (tout du moins sur Mac, pour Windows et iOS c'est à vérifier). - JPEG XR, est le bébé de Microsoft (c'est une évolution normalisée de HD Photo), plus rapide que JPEG 2000, avec plein de profondeurs de composants entre autre pour le HDR, mais il me semble avoir lu un article (Charles Bloom à tout les coups) qui le descendait proprement en flamme ; IE9 et plus peuvent l'afficher. Pour en revenir à WebP, proposer la compression avec perte et une couche alpha n'est pas en soi nouveau mais le format apporte également une très bonne compression sans perte et l'animation, la libwebp est là pour faciliter son adoption. Bien qu'a priori tous les acteurs du Web auraient à y gagner, Google peut très bien échouer dans cette entreprise, car Google n'est que Google et pas le W3C, et tout le monde n'aime pas nécessairement ce que fait Google. Ce ne serait pas la première fois qu'un problème d'ego ou de syndrome NIH (Not Invented Here « pas inventé ici ») mettrait à mal un format d'image, le non support du JNG/MNG dans le but de favoriser l'APNG chez Mozilla est assez édifiant. Je n'ai pas parlé d'Opera Mini et d'Opera Turbo, tout comme je n'ai pas parlé du mod_pagespeed pour Apache, car manipuler du WebP en coulisse c'est très bien si ça permet d'augmenter les performances, mais ce n'est a priori pas ce qui va rendre le format populaire et donc assurer son succès. Par ailleurs la conversion au vol c'est bien, mais ça ne permet pas d'exploiter la quintessence du format (application successive de deux compressions destructives ou optimisations des pixels totalement transparents pour le PNG qui ne conviennent pas à WebP). Pour finir, je n'ai pas noyé l'article sous les chiffres de comparatifs PNG/WebP car l'encodeur WebP est encore jeune et a quelques lacunes à combler (avec les images en niveau de gris en particulier). La version 0.2.0 de la libwebp et les spécifications associées sont là pour figer le format. Un face à face avec GIF, PNG, JNG ou JPEG 2000 est encore prématuré à mes yeux, mais d'autres le feront surement, pour l'instant je remonte mes résultats vers l'équipe qui développe WebP pour orienter les bidouillages sous le capot.

Par : PASQUIOU Richard

riplay777@hotmail.com — Fri, 10 Aug 2012 15:57:20 +0000

Karl DUBOST réagit à cet article ici. Pour moi, il en a eu une mauvaise lecture : Nulle comparaison franche n'est établie entre JPEG et WEBP (juste un exemple). Mais il y apporte aussi quelques bons compléments.

Par : Frédéric Kayser

cryopng@free.fr — Tue, 07 Aug 2012 22:21:48 +0000

Pour Linux et Mac OS X un script Bash un peu ancien, mais une base intéressante: http://lyncd.com/2009/03/imgopt-lossless-optimize-png-jpeg/ Si certains veulent se lancer dans ce genre de chose, n'hésitez pas à me contacter, enfin surtout sur Linux et Mac OS X. Mes scripts perso sont plutôt destinés à presser le citron jusqu'à la dernière goûte, sans contrainte au niveau du temps nécessaire ou des ressources CPU sollicitées (il est assez facile de paralléliser les traitements et aller jusqu'à consommer toute la puissance de calcul d'une machine), c'est pourquoi CryoPNG est bien plus lent qu'ImageOptim.

Par : Frédéric Kayser

cryopng@free.fr — Mon, 06 Aug 2012 20:04:39 +0000

Procéder à des optimisations d'images en masse n'est pas nécessairement compliqué ; de nombreux outils d'optimisation sont des programmes shell/ligne de commande à la base (gifsicle, pngout, pngcrush, defluff, cryopng, pngwolf, jpegtran...). Tant que l'on reste dans le domaine des optimisations sans perte il n'y a normalement pas besoin de contrôle visuel systématique, JPEGmini ouvre de nouvelles perspectives... mais il faut lui faire une confiance aveugle. Avec des machines assimilées Unix et quelques connaissances au niveau shell pour écrire des scripts, exploiter des commandes comme « find » ou programmer le cron, développer des solutions sur mesure est relativement simple, c'est le contexte que je connais le mieux. Convertir toutes les images GIF d'un répertoire en PNG peut se faire avec un simple « pngout -q *.gif », après si l'on veut convertir en PNG uniquement les GIF qui ne contiennent qu'une image et confier les animations à gifsicle ça demande d'identifier les animations au préalable « identify » d'ImageMagick peut faire ça. Avec un volume journalier de 10000 images le plus dur risque d'être de doser le niveau d'optimisation, car mine de rien pngcrush et surtout pngout peuvent facilement prendre plus de 10 secondes par image même en parallélisant les traitements il faudra certainement faire des concessions pour tenir la cadence. Si tu veux m'en dire plus par courriel tu peux m'écrire à cryopng (arobase) free (point) fr.

Par : Boris Schapira

borisschapira@gmail.com — Mon, 06 Aug 2012 11:29:02 +0000

Excellent article, Frédéric, merci. Par contre il reste un voilà à soulever, celui de l'industrialisation du traitement d'images. Il est assez facile de tomber sur des articles qui explique comment optimiser une image, mais plus rare de trouver quelque chose qui parle de l'optimisation de 10'000 images/jours (tous formats confondus, notamment GIF), par exemple. Si tu as des pistes, je suis preneur :)

Par : Mehdi Kabab

pioupioum@gmail.com — Fri, 03 Aug 2012 11:14:05 +0000

Merci pour cet article fort intéressant et qui, pour une fois, précise que JPEGMini n'obtiendra pas de bons résultats sur des JPEG contenant des éléments textuels (le résultat est tout simplement horrible tant il y a d'artefacts). Concernant WebP, un plugin GIMP est disponible pour lire et écrire dans ce format prometteur : WebP Import / Export.

Par : Franck Lepaire

franck.lepaire@gmail.com — Fri, 03 Aug 2012 09:49:17 +0000

Article très intéressant ! Merci.

Par : PASQUIOU Richard

riplay777@hotmail.com — Wed, 01 Aug 2012 14:48:28 +0000

Excellent article. Bonne explication du fonctionnement de JPEGmini. Et excellente découverte pour moi que ce webP. Merci Frédéric.