Mozilla n'aime pas le WebP de Google

Je dois être aveugle mais le webp ne semble pas degueux: il aurait fallut mettre l'originale à coté pour bien faire.

Dans tout les cas, pour des sites web, la différence de taille de l'image, et donc la bande passante nécessaire, sont tellement énorme que je vois mal pourquoi Mozilla bloque.

PS: je ne suis pas pro-google et je utilise principalement Firefox (et IE pour les trucs pro).

Tu ne vois pas ? Relis le...

Ils nous font n'importe quoi Firefox. Si ça permet de gagner 4 fois plus de vitesse en chargement image, faut être stupide pour pas intégrer cette technologie.

Et puis lible au créateur de site Web de choisir d'afficher ses images en JPG ou WebM, c'est lui que ça regarde, je comprends vraiment pas la politique de Firefox sur ce coup là.

Vu que les tests sur des humains montrent qu'ils n'apprécient pas la compression sauvage de WebP, si tu veux juste gagner de la place autant compresser un peu plus ta jpeg... Pas besoin de nouveau format pour ça.

Se pose aussi la question du Google qui veut petit à petit remplacer tous les formats et produits qu'on utilise... Ça rappelle assez MS du temps de sa splendeur, et c'est plus que dérangeant.

C'est la politique du "Est-ce vraiment bien nécessaire d'avoir encore une nouvelle technologie ?". Heureusement que tout le monde n'a pas cette politique, sinon l'informatique aurait du mal à avancer.

Comme le dit Maxmiz, c'est au webdesigner de choisir le format le plus approprié.

Cela dit pour défendre Mozilla, c'est du temps de développement, d'intégration et de test ; il faut donc réfléchir si ça vaut vraiment le coup.

@Mhray et @LVM: je suis humain et je ne suis pas gêné... je dois être le seul vu vos remarques.

J'aime anti-aliasing! C'est mal docteur?

Au fait, compresser plus en jpeg, c'est souvent très très moche.

LVM : à la grosse différence de MS... il s'agit là d'un format ouvert et libre et Google ne percevra rien sur l'utilisation de ces formats.

MS n'a pas proposé de format d'image dans l'affaire. Le GIF c'est compuserve.

Et le jpeg 2000 dans cette histoire c'est aux oubliettes ????

Rien que le fait que le format ne prenne pas en charge la transparence me fait penser qu'il n'apporte strictement rien face au JPG.

Si déjà on essaie d'imposer un nouveau format la moindre des chose serait qu'il comble certaines lacunes du format que l'on souhaite remplacer.

Et si en plus les balises metadonnées sont moins bien fournies... c'est encore plus un retour en arrière.

Un chose n'est pas claire dans l'article WebP est libre ou pas?
Si c'est libre je vois pas où est le problème pour Mozilla.

Par contre, je suis d'accord avec google pour une course à la compression qui aurait du être lancé depuis bien longtemps.
Vu que la data sur mobile n'est pas illimitée,(et pour les faibles débits adsl) ça devient indispensable de maitriser la taille des fichiers et des codes que l'on doit télécharger.

Et d'ailleurs si on pouvait optimiser les OS et les programmes dans ce sens, ça serait pas du luxe surtout avec les SSD actuels aux volumes étriquées.

Les balises meta on s'en fout. C'est un format pour afficher des images sur internet, pas pour échanger ses photos de famille. As-tu déjà regarder les méta d'un avatar ou un logo sur le forum ? je ne pense pas. Et ca sert a quoi de trimballer des données qui ne servent a rien ? a rien . Par contre pour le webmaster si ca lui permet de gagner sensiblement en bande passante sans pour autant trop perdre en qualité, je pense qu'il sera content. Sur un site de partage de photos par exemple tu peux encoder toutes les miniatures et aperçu grande taille de tes photos, et garder les jpg pour affichage pleine taille avec les meta et tout le reste. Et si a qualité egale il gagne 40% de volume. Je pense que sur une page on peux facilement gagner 100ko. Si on multiplie cela par le nombre de page affiché par jour. ca peut être intéressant en coût d'hébergement.

Après pour la transparence, le png est là pour cela. Disons que Jpg, webm c'est plutot pour de la photos, png gif plutot pour des images/logos.

Non : si tu as un écran bas de gamme, tu ne verra jamais la différence. Ça dépend donc essentiellement de ton budget sur ce coup là... Après, même sans chercher à devenir photographe (loin de là), l'œil est comme le reste : il s'éduque et c'est gratuit. Ça demande juste un peu d'exercice (efforts d'observation, de comparaison, d'essais, d'apprentissage, etc.)... Et, sauf exceptions dont je ne pense pas que tu sois, nous sommes tous capables de le faire, au moins un minimum.



Non, sauf si tu utilises des logiciels avec de mauvais algorithmes ou si tu ne sais pas utiliser ceux qui en ont des meilleurs voir des carrément bons.

On peut aussi extrapoler pour se poser la question de l'algo (et ses réglages) utilisé par Google pour présenter son "comparatif".

Juste pour info : XnView compresse mieux le JPEG que Photoshop grâce à l'emploi d'algorithmes différents. Et XnView est gratuit . D'ailleurs, Photoshop lui-même arrive à fournir de meilleurs résultats visuels en qualité 6 qu'en qualité 7 ! Pourquoi ? La faute au sous-échantillonnage moins bien équilibré en "7". Le JPEG n'est pas un truc simpliste, c'est bien de se renseigner un peu (pour ça il y a Google, Wikipedia et bien d'autres).




Oui, je le crains. En tout cas personne ne se bouscule pour l'imposer malgré ses évidentes qualités. Du coup, face au JPEG vieillissant et au PNG plus que lourd en 24 bits avec ou sans transparence (la sempiternelle compression sans pertes !), la place se libère pour que Google et sa position de monopole de fait s'y engouffre ou tente de le faire. Logique.

Je propose de revenir en GIF87. Pas de transparence et 256 couleurs max...

Et pour ceux qui pleurent leur bande passante, il reste le minitel !

Et pourquoi pas un format unique capable de tout gérer ?
un format capable de compression sans trop de perte avec balises etc pour les photos, mais aussi qui puisse compresser fortement en cas de besoin kit à faire l'impasse sur les balises.. et gérer la transparence pour ceux qui le souhaitent.

Qu'on ne me dise pas que c'est impossible!

Par ex le H.264 est capable de cela pour la vidéo: il s'adapte aussi bien aux besoins d'appareils mobiles à la faible puissance et bande passante, tout comme il peut servir pour encoder les meilleurs BluRay. On ne saurai pas faire cela pour des images fixes? Beuh !!

C'est pas faux okey-dokey, mais bon un format unique qui fait tout bien ... meme si c'est pas impossible, ces 2 concepts sont souvent incompatible. C'est comme bonne qualité et petite taille

Sinon j'ai vérifié mes chiffres, en affichant la page tom'hardware
Sur un total de 580Ko il y a 448Ko d'images, avec un gain de 25% en moyenne mini grâce au web-p on gagne au moins 110Ko, par home chargée.

Et sur une page Facebook sur 200Ko, y'en a 100 d'image. donc 25Ko par page chargée.
a 777 000 000 000 pages vues par mois. ca fait du 19 425 000 000 000 000 octets
donc 19 425 To d'économisé par mois. si je me suis pas loupé sur les unités.
C'est pas négligeable.

source :
http://www.google.com/adplanner/static/top1000/
http://code.google.com/speed/webp/gallery.html

Intéressant. C'est vrai que la différence n'apparait pas flagrante quand on regarde les exemples et l'écoomie est substancielle. Mais quand on voit que le svg n'est toujours pas implanté correctement, on se dit que c'est pas gagné cette affaire.

Microsoft a le JPEG XR.

@moimadmax
Tom's hardware est un très mauvais exemple, ils arrivent à charger plusieurs fois les mêmes éléments dans dans fichiers PNG qui ne sont pas optimisés (pngout, cryopng, pngwolf, deflopt, defluff c'est pas fait pour les chiens).

Regardez un peu ça:
http://m.bestofmedia.com/i/tomshar [...] rites5.png
http://m.bestofmedia.com/i/tomshar [...] go.0.1.png
http://m.bestofmedia.com/i/tomshar [...] rites3.png

sprite5.png fait 14840 octets
Il contient :
- un chunk tEXt qui indique quel logiciel l'a créé (Adobe ImageReady, déjà ça commence mal).
- un chunk tRNS avec 256 entrées de transparence ce qui voudrait dire que les 256 couleurs de la palette ont toutes un niveau de transparence !

Un simple pngout -v -n3 -c3 sprites5.png
réduit le fichier à 13690 octets (soit 1150 octets de moins, 7% plus petit)
et curieusement dans la version améliorée:
chunk tRNS at offset 0x00331, length 1: 1 transparency entry

Mais ce n'est pas étonnant, très peu de webmestres sont formés à l'optimisation des images ou aux performances web en général, c'est tellement plus simple d'acheter un serveur plus puissant et payer pour 10 GiB de plus l'hébergement mensuel, et tant pis pour le pékin moyen qui accède au site en 3G avec un abonnement illimité (limité à 500 MO) ou le francophone du bout du monde défavorisé, y zont qu'a vivre à Paris et avoir la fibre.

Pourquoi devrait-ce être incompatible ?

Tu as besoin de fichiers de petites tailles=> tu sacrifie (plus ou moins) sur la qualité
Tu as besoin d'une bonne qualité => tu utilises des fichiers de plus grande taille.


Ces deux concepts sont parfaitement compatibles, et mine de rien le JPEG y réponds pour la plupart des gens. Les photos prises par leur APN 10Mpx sont stockées en JPG sans trop de compression, et quand ils les collent sur leur Facebook ces mêmes photos sont réduites, compressées pour ne pas être trop lourdes tout en restant suffisamment lisibles pour l'usage.

Et comme dit quand je vois que le H.264 répond parfaitement à cette problématique via les différents profils offerts, je me demande pourquoi on ne pourrait pas appliquer le même système aux images fixes.

On ne parle pas forcément de chercher le truc qui va balancer des fichiers de 100ko pour une qualité top moumoute digne d'un format RAW. Le tout c'est d'avoir la compression qui correspond à l'usage, avec ou sans les dégradations que cela suppose. Un seul format pourrait très bien faire cela.

@cavewoman : Commentaire très intéressant et utile. Je rajouterais que c'est comme la multiplication des éléments dom dans une page, ce qui alourdit son traitement et les algo js concernés. Mais on sort du sujet. Perso, je ne vois pas l'intérêt de ce nouveau format. On peut très bien améliorer l'existant et on peut laisser libre le développeur de compresser son image comme il le veut avec les formats existants. Rajouter un traitement dans le navigateur, surtout concernant les images, ne fera qu'alourdir/ralentir le rendu. Mais bon... On verar bien !

ou ça rappelles apple aujourd'hui avec son itune, sa "mcro-sim", son connecteur propriétaire et j'en passe ... je ne trouves pas que cela soit guère mieux. Seule différence avec microsoft ou google : apple n'a aucune chance d'imposer ses formats, mais l'intention de le faire et bel et bien là

Cette page fait 25,4ko avec... AdBlock. Soit un gain de 95%.

Je te donne une raison pour l'imcompatibilité (une parmi d'autre) :
Si tu regardes un peu comment fonctionne le PNG tu vois qu'il utilise les couleurs indexé et une palette de couleurs (cf chapitre 4.3.3 du lien de ce lien) ce qui permet pas mal de gain en taille d'image dans le cas d'un logo car un logo réutilise souvent les mêmes couleurs et en utilise rarement plus de 256 ce qui réduit d'autant la taille de la palette.
Ca marche bien car PNG utilise une compression sans perte donc les pixels ne sont pas modifiés par l'algo.
Maintenant pour les photos (qui utilise généralement beaucoup plus de couleurs qu'un logo) le PNG n'est pas ce qui se fait de mieux pour avoir un bon rapport poid/qualité puisqu'il ne permet pas la compression avec perte.
Il est, à mon avis, assez difficile d'améliorer le PNG pour ce qui est de la gestion des logos et y intégrer la gestion des photos reviendrait à y intégrer un nouvel algo de compression et de manipulation interne, donc autant utiliser un autre format directement.

Je pense que Mozilla a raison de pointer du doight les défauts d'un futur formats que google va tenter d'imposer (pas de gestion des profil couleurs dans les métadonnées, compression discutable).
L'algo de WebP est il vraiment ce qui se fait de mieux à l'heure actuel ? On n'as pas besoin d'un autre format si il n'apporte rien de plus que ce qui existe déjà.
La compression par ondelette semblait donner de très bon résultats (pgf, jpeg xr, jpeg 2000) c'est avec ces formats là qu'il faudrait comparer WebP.

Honnêtement je ne vois pas ce qui empêche de développer un format qui sache jongler entre les deux: compression avec ou sans perte, Balises pas balises, Transparence, pas transparence, etc)

Je ne parle pas forcément de prendre un format existant et juste de l'améliorer, mais kit à proposer un nouveau format pourquoi ne pas remettre les choses à plat et proposer un format véritablement adaptable à l'usage. Ca ne me parait pas inconcevable qu'on puisse coller un réglage au niveau des logiciels qui génèrent les images qui permette de choisir quel mode on utiliser.

Après tout quand on crée des GIF on a le droit à moult réglages pouvant faire varier la taille et l'aspect de l'image dans de grandes proportions. Iden pour le JPEG on a déjà pas mal de choix lors de la création (genre le JPG progressif, etc).

Il "suffit" d'un flag pour dire qu'on utilise tel type de compression (choisi par l'utilisateur selon la destination de l'image), ensuite le logiciel qui affichera l'image se basera sur ce flag pour choisir la méthode de lecture... etc ...

Comme IFF ou TIFF?

okey-dokey> Ok, maintenant je vois l'idée : en gros ça serait un "méta-format" qui choisit l'algorithme à utiliser en fonction d'un entête (ou flag).

Mais un format c'est un algo de compression/décompression lié à une organisation interne (rangement des données). Cette organisation interne est définie de manière à faciliter ou rendre plus performant le format en fonction de l'algo.
Si maintenant on fait un meta-format multi algo il y aura surement des représentations différentes.
En gros ça reviendrait quasiment à mettre un format d'image (jpeg,png,... whatever) dans un zip (zip ou autre format de compression).
Ca serait donc plutôt un conteneur (comme avi, mkv pour la vidéo ou tiff pour les images).

A noter que H264 ne fonctionne pas comme cela (ce n'est pas un conteneur) : en effet les differents profils du format ne change en rien la représentation interne des données du format et l'algo (utilisation de transformée discréte, transformé de hadamard, codeur entropiques, filtres... etc) n'a ""que"" quelque paramètres activé ou non (suivant le profil) qui change, par exemple, le nombre de bit pour la représentation d'un pixel ou l'algo utilisé par les codeur entropique.


Parenthése sur le JPEG :
"si tu veux juste gagner de la place autant compresser un peu plus ta jpeg... Pas besoin de nouveau format pour ça"
-> et l'image aura des artifacts caractèristiques du JPEG et de sa transformé DCT