Ce format utilise la technique de compression utilisée pour les images clés du VP8 (le codec vidéo du WebM) et comme conteneur un format dérivé des spécifications RIFF qui autorise les métadonnées.
Pourquoi créer un nouveau format d'image ? Parce que les formats actuels datent d'au moins 15 ans et, depuis, des progrès ont été accomplis. Il y a bien eu JPEG 2000, mais il n'a jamais vraiment percé. En outre, lors de la consultation d'une page Web, Google estime qu'en moyenne, 65% des données sont pour les images. Améliorer le taux de compression améliore nécessairement le temps de chargement (et d'affichage) des pages.
Le support de l'affichage du WebP dans les navigateurs est pour l'instant sous la forme d'un patch pour WebKit. Mais il y a des chances qu'il arrive rapidement pour Firefox et Opera. Car tout cela est, comme pour le VP8, libre de droit.
Aller plus loin
- Le site officiel avec les specs (37 clics)
- L'article Wikipédia fait avec amour (44 clics)
- L'étude comparative par rapport à d'autres formats (31 clics)
# P ?
Posté par DLFP est mort . Évalué à 9.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: P ?
Posté par Emralegna . Évalué à 8.
[^] # Re: P ?
Posté par JoeltheLion (site web personnel) . Évalué à 6.
# JPEG2000
Posté par Prae . Évalué à 5.
Sur le web, tu veux dire.
Parce que sinon: http://en.wikipedia.org/wiki/JPEG_2000#Applications_of_JPEG_(...)
Et notamment au cinéma numérique, où c'est juste la référence: http://dcimovies.com/DCIDigitalCinemaSystemSpecv1_2.pdf (page 39)
[^] # Re: JPEG2000
Posté par Yannick (site web personnel) . Évalué à 1.
Google me dit que ça s'appelle "JPEG XR" maintenant. Mais toujours pas plus entendu parler...
[^] # Re: JPEG2000
Posté par Naha (site web personnel) . Évalué à 1.
[^] # Re: JPEG2000
Posté par Yannick (site web personnel) . Évalué à 2.
[^] # Re: JPEG2000
Posté par Prae . Évalué à 2.
C'est que mon point de vue, et probablement qu'un spécialiste du genre aura une autre interprétation.
Après le truc de licence, je suis pas sûr que cela soit à cause de cela, car les premières tranches du JPEG2000 sont "libre" (dans le sens où les gens qui ont signés auprès du consortium avaient obligation de déposer les "armes-brevets"); Après ce sont les autres tranches du JPEG2000 qui sont sous brevets, mais des éléments qui - me semble - ne sont pas ou peux utiliser (et qui n’empêche pas d'avoir du JPEG2000 dans plusieurs formats et utilisable, quand même; donc je doute de cette pertinence...)
De plus le GIF et le MP3 l'étaient aussi, cela n'a pas empêché de se faire une solide place au soleil.
[^] # Re: JPEG2000
Posté par jeberger (site web personnel) . Évalué à 4.
J'ai même envie de dire: vu les difficultés que le PNG a eu pour remplacer le GIF alors qu'il est nettement supérieur sur tous les points (compression, qualité, transparence, brevets, ...) c'est pas étonnant que le JPEG200 n'aie pas percé face à JPEG vu qu'il n'apporte que de la compression au prix de problèmes de brevets. En plus les débits des accès internet et les capacités des disques sont tels que la différence de compression n'est pas vraiment significative.
Pour la même raison, je ne crois pas trop au succès du WebP...
[^] # Re: JPEG2000
Posté par Troy McClure (site web personnel) . Évalué à 4.
pas sur tous les points, parce que le gif permet de faire ces petits images animées qui font la joie des petits et des grands.
[^] # Re: JPEG2000
Posté par jeberger (site web personnel) . Évalué à 5.
[^] # Re: JPEG2000
Posté par Littleboy . Évalué à 5.
Mozilla n'en veut d'ailleurs pas et l'a vire depuis Mozilla 1.5 et a developpe un format concurrent (qui n'a pas decolle non plus) APNG.
On est bien loin d'une solution deployee comme le PNG a pu l'etre, donc avant que ca se pose comme remplacant de GIF, il va se passer du temps.
[^] # Re: JPEG2000
Posté par djano . Évalué à 2.
Pour tout le reste GIF sera encore utilisé mais les utilisations qui restent semblent plus marginale.
[^] # Re: JPEG2000
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: JPEG2000
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Je verrais bien fleurir des sites web plein de photos, avec une note « retrouvez nos photos en meilleure qualité en utilisant un meilleur navigateur ».
[^] # Re: JPEG2000
Posté par tesiruna . Évalué à 3.
> retrouvez nos photos en meilleure qualité en utilisant un meilleur navigateur
Il ne manque plus que de faire du lobbying auprès de sites pour adultes.
[^] # Re: JPEG2000
Posté par Yannick (site web personnel) . Évalué à 2.
[^] # Re: JPEG2000
Posté par Eolis . Évalué à 1.
Commet google va convaincre Canon, Nikkon, Olympus, Fuji, Sony, Nokia, HTC, et tout les autre fabriquant integrant des appareil photo dans leur produit, d'investir de l'argent dans l'implementation d'un format sans aucun retours sur investissement possible ? Car si un appareil ne porte pas la mansions webP on l'achetera quand même car les jpeg peut-etre lu dans 99% des configuration, alors que si un appareil porte la mansion webp mais pas la mansion jpeg ...
[^] # Re: JPEG2000
Posté par boq . Évalué à 1.
s/mansion/mention/
[^] # Re: JPEG2000
Posté par Eolis . Évalué à 1.
# « fait avec amour » ?
Posté par grondilu . Évalué à 1.
[^] # Re: « fait avec amour » ?
Posté par grondilu . Évalué à 5.
# Comparatif
Posté par Anonyme . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparatif
Posté par Guillaume Chanaud (site web personnel) . Évalué à 3.
[^] # Re: Comparatif
Posté par Seb . Évalué à 1.
[^] # Re: Comparatif
Posté par olivierweb . Évalué à 1.
Il y a une coquille dans la légende de l'image, c'est WebP et non Webp.
Merci pour les éclaircissements.
[^] # Re: Comparatif
Posté par Anonyme . Évalué à 1.
J'ai utilisé cette photo car elle réunie justement plusieurs caractéristiques intéressantes : elle a des textures fines, des zones de contrastes, des zones floues et des zones sombres.
J'ai compressé la photo avec l'outils fournis par google (après l'avoir compilé sous debian) en laissant les paramètres par défaut, voyant qu'on obtenait un fichier de moins de 100ko, j'ai ensuite compressé l'image au format jpeg en utilisant l'outils de gimp afin d'obtenir un fichier en sortie de la taille équivalente au fichier webp (ce qui correspond à un réglage de 45 dans gimp).
Je vais ajouter des agrandissements de détails sur l'image pour voir plus facilement les différences.
[^] # Re: Comparatif
Posté par jbbourgoin (site web personnel) . Évalué à -1.
Le webp est d'une qualité égale au png, et le jpg légèrement inférieur.
[^] # Re: Comparatif
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
Sur la page de WebP chez google, il y a des exemples bien plus parlants: à qualité égale, des tailles jusqu'à ~70% plus petites.
Mathias
[^] # Re: Comparatif
Posté par Éric (site web personnel) . Évalué à 4.
Le PNG est un format sans perte. Qualité équivalente ça voudrait dire "exact au pixel près".
JPEG *et* WebP ne sont pas "légèrement inférieurs", mais carrément différents. Ce sont des formats "à pertes". Le fichier compressé ne sera jamais équivalent ou à qualité égale avec l'image originale.
Webp ne peut pas être de qualité égale au png, c'est "by design". Il sera toujours équivalent au jpeg.
D'ailleurs j'aimerai bien avoir des précisions sur l'image de wikipedia. Elle ressemble beaucoup à une photo et très probablement la source initiale est une jpeg ... donc la remettre en png n'a pas de sens.
[^] # Re: Comparatif
Posté par Naha (site web personnel) . Évalué à 5.
Rien n'empêche de développer un RAW directement en PNG…
[^] # Re: Comparatif
Posté par Éric (site web personnel) . Évalué à 1.
En tout cas le webp de qualité équivalente au png, je maintiens, bullshit (ou foutaises, comme tu préfères)
[^] # Re: Comparatif
Posté par Jerome Herman . Évalué à 9.
A l'oeuil je ne voyais aucune différence donc j'ai fait une soustraction du png sur les deux autres parties.
Comme je ne voyais toujours rien j'ai boosté le contraste par niveau
Voici le résultat :
http://www.monsitealacon.fr/erreur_webP.png
(J'ai laissé apparent le réglage Gimp pour que ceux qui veulent me troller puissent le faire depuis une base solide)
Au niveau geométrie pure, le WebP est légèrement devant, celà est particulièrement visible dans les contours de l'objet par rapport au fond. Par contre au niveau couleur c'est une catastrophe. Le WebP a plus de zones en erreur et les erreurs sont plus graves.
(Les erreurs sont les couleurs apparentes, plus elles sont vive plus l'erreur est importante)
En plus le Jpeg fait des erreurs assez joliment réparties, alors que le WebP semble faire des gros paté d'erreurs en macro blocs.
Plus inquiétant la dégradation du fond pourtant relativement uni en rubans dans lesquels l'erreur ne cesse de croitre quand on va vers le bas et ce jusq'au macroblock suivant.
Ceci étant, comme on le voit sur la courbe toute l'erreur ou presque est concentré dans une intensité de 5,05 sur 255. Soit peanuts.
Pour l'instant je ne suis pas vraiment convaincu. par le format.
[^] # Re: Comparatif
Posté par Sylvain Sauvage . Évalué à 4.
[^] # Re: Comparatif
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Un personne avait d'ailleurs poster un lien vers un projet de lib d'évaluation de comparaison d'image qui voulait proposer une méthode meilleurs, que le SNR.
Derrière l'oeil humain, le cerveau fonctionne beaucoup. Par exemple, la sensibilité de l'oeil dans la lumière est de l'ordre de 24 bits or est plutot de 7 bits dans la couleur, idem pour la résolution qui est plus précise en lumière qu'en couleur. On peut aussi ajouter que l'oeil humain est peu sensible au texture et énormément aux formes.
Bref, tout cela va bien plus loin qu'un simple diff.
"La première sécurité est la liberté"
[^] # Re: Comparatif
Posté par Laurent Martelli (site web personnel) . Évalué à 1.
# Une analyse exterieure
Posté par Littleboy . Évalué à 10.
http://x264dev.multimedia.cx/?p=541
Conclusion: les memes defauts que VP8 (encodeur defaillant qui optimise uniquement pour le PSNR), vu que c'est base entierement dessus.
Pour l'instant c'est quand meme 100% du marketing et de l'effet d'annonce de la part de Google. Il manque des tonnes de fonctionnalites de JPEG, et pour l'instant ca ne rajoute meme pas les choses manquantes (alpha, etc.). Aucun doute que certaines de ces choses vont etre implementees au fil du temps (meme si Google a semble-t-il declare ne pas vouloir implementer certaines choses).
Par ailleurs, en achetant On2, ils ont aussi recupere l'equipe marketing et ses comparaisons foireuses:
- Comparaison en reencodant l'image JPEG (et pas la source), avec ses artefacts de compression, avec des gains plus importants au niveau compression a la clef
- Utilisation du PSNR pour comparer les images (alors que c'est pas vraiment une bonne variable pour comparer la qualite reelle)
Et surprise, surprise, VP8 est justement optimise pour ca et donne de tres bon resultats. Et d'apres le post de Dark Shikari, des qu'on part de la source et qu'on regarde autre chose que le PSNR, c'est tout de suite mon reluisant.
En tout cas, bonne chance a Google, apres JPEG2000 et JPEG-XR qui n'ont jamais decole sur le web (alors qu'ils faisaient plus et/ou mieux que JPEG contrairement a WebP pour le moment), ils s'attaquent a gros.
[^] # Re: Une analyse exterieure
Posté par patrick_g (site web personnel) . Évalué à 2.
Par exemple dans l'article que tu pointes il y a un mensonge gros comme une maison:
Dark Shikari : "it doesn’t even support all of JPEG’s features, let alone many of the much-wanted features JPEG was missing (alpha channel support)"
[SNIP]
"Google doesn’t seem interested in adding any of these features either".
L'annonce de Google : "We plan to add support for a transparency layer, also known as alpha channel in a future update".
[^] # Re: Une analyse exterieure
Posté par Littleboy . Évalué à 7.
Mmmmm, mais que ce que c'est que ce SNIP? Peut-etre justement une description des fonctionnalites que Google n'a pas l'intention d'implementer? Non, ca serait trop gros, pas possible...
It only supports 4:2:0 chroma subsampling, while JPEG can handle 4:2:2 and 4:4:4. Google doesn’t seem interested in adding any of these features either.
Je pense que Dark Shikari est capable de lire l'annonce de Google, et que donc il parle bien du chroma subsampling et pas du tout du support de l'alpha.
Je pense donc que tu as mal lu et que tu as vire a tord la partie interessante du message.
[^] # Re: Une analyse exterieure
Posté par patrick_g (site web personnel) . Évalué à 4.
Premisse mineure : Google de son côté dit qu'il ont prévu d'ajouter l'alpha.
Conclusion du syllogisme : L'affirmation de Dark Shikari est donc factuellement fausse.
J'ai voulu mettre en évidence ce fait et c'est pourquoi j'ai effectué ces citations en mettant bien en évidence les parties contradictoires des phrases. Pour bien les mettre en évidence il faut couper ce qui n'est pas pertinent et qui parasite la lecture pure du syllogisme. Évidemment dans un souci d'honnêteté il faut indiquer au lecteur la coupe qui a été effectuée (d'où le [SNIP]).
[^] # Re: Une analyse exterieure
Posté par Littleboy . Évalué à 2.
J'arrive a exactement l'oppose de ta conclusion, c'est tout a fait logique (le "any" se refere a la phrase precedente et uniquement elle) et c'est exactement a l'oppose de ta propre conclusion. Comme quoi, c'est facile de torturer la logique pour arriver a la conclusion qu'on veut.
Pour les personnes qui n'aurait pas lu l'annonce de Google, je peux comprendre qu'elles soient troublees. Mais a partir du moment ou tu as vu que c'est dans les choses prevues, on peut parfaitement le lire comme je le fais.
En tout cas, c'est corrige depuis sur le blog (pointe par un mec de Google qui n'etait pas d'accord non plus), tu devrais etre content (mais c'est remplace par autre chose de non prevu, haha...)!
[^] # Re: Une analyse exterieure
Posté par Moonz . Évalué à 3.
[^] # Re: Une analyse exterieure
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une analyse exterieure
Posté par Mjules (site web personnel) . Évalué à 8.
[^] # Re: Une analyse exterieure
Posté par steph1978 . Évalué à 3.
je pense qu'ils partent mieux armés:
- format libre de brevet et de redevance
- implémentation linux déjà dispo
- implémentation dans webkit et donc chrome et safari
- qui sait une implémentation dans les mobiles android
- dans leur moteur de recherche d'images, ils pourraient mettre en avant le format
bref, ils ont plusieurs angles d'attaque pour que la sauce prenne.
# Encore de la compression avec perte ?
Posté par Kekun (site web personnel, Mastodon) . Évalué à -3.
Enfin, c'est un format fait pour visualiser des images, par pour les retravailler, il ne remplacera pas le PNG.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Encore de la compression avec perte ?
Posté par tiot (site web personnel) . Évalué à 10.
Bref le PNG est un concurrent du gif pas du jpeg.
[^] # Re: Encore de la compression avec perte ?
Posté par jeberger (site web personnel) . Évalué à 1.
Euh, non, PNG utilise LZ79, pas LZW. C'est proche mais ce n'est pas la même chose. En particulier LZW était encombré par des brevets jusqu'à peu alors que LZ79 était libre (l'un des gros arguments dans la bataille contre le GIF).
L'objectif n'est pas de remplacer le PNG, mais de proposer un nouveau format ouvert, plus performant que le Jpeg, pour enregistrer des images pour le web. Le choix du PNG ou du Jpeg/WebP dépend bien entendu du type d'image que l'on veut insérer dans une page Web.
D'accord avec cette partie du message.
Évidement on utilise pas de formats compressés pour enregistrer des images que l'on doit retravailler.
Euh, si, mais on utilise une compression sans perte type PNG, RAW (ben oui, les formats RAW des appareils photos sont compressés)...
[^] # Re: Encore de la compression avec perte ?
Posté par MrLapinot (site web personnel) . Évalué à 6.
Tu as entendu parler de l'entropie de Shannon ?
[^] # Re: Encore de la compression avec perte ?
Posté par ʭ ☯ . Évalué à 4.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Encore de la compression avec perte ?
Posté par bubar🦥 (site web personnel) . Évalué à 5.
# Libre !
Posté par j_kerviel . Évalué à 10.
Car tout cela est, comme pour le VP8, libre de droit.C'est sous licence Créative commons libre (by) et google fournit une implémentation sous licence BSD modifiée.Il serait donc préférable de dire libre plutôt que libre de droits qui n'apporte rien sinon une confusion dans l'esprit du grand public avec le domaine public et l'abandon des droits (ce qui n'est pas le cas ici).
# mouais
Posté par Éric (site web personnel) . Évalué à 10.
- Le format jpeg est vieux, on peut faire mieux actuellement.
- Le jpeg2k fait ça mais n'a pas percé, alors on lance le notre qui (forcément) est encore moins répandu
- Regardez, en prenant des images au hasard sur Internet on peut gagner 39% en moyenne avec une dégradation faible "non visible" de l'image
Et c'est ce dernier argument que j'achète le moins.
- Ceux qui ont déjà essayé savent qu'en retirant toutes les méta-données des images on gagne déjà un volume non négligeable. WebP n'ayant pas pour l'instant de méta-données, il est forcément plus petit. Retirer les vignettes embarquées et les méta-données ça peut déjà être fait dans jpeg, et côté performance web on conseille déjà de le faire justement pour gagner en volume.
- Si vous regardez, la plupart des images jpeg sur le web sont enregistrées avec franchement trop de qualité pour ce qui est nécessaire. On trouve pas si rarement des 95 ou 99%, rarement en dessous de 90%.
Souvent (pas tout le temps) baisser à 80% ne montre pas d'artefact horrible, et on gagne facilement du poids sur l'image.
Un gain moyen de 39% sur un échantillon jpeg aléatoire du web, en retirant les méta-données et en s'autorisant une perte légère mais peu visible de qualité, je sais faire aussi hein. Pas besoin de changer de format de fichier pour ça.
Bon, je ne nie pas qu'ils ont pu faire une compression un peu meilleure à qualité visible égale, je leur fait confiance, mais le résultat ne me semble franchement pas justifier "encore un format de plus". Donc, à part, "oui mais celui là c'est *notre* format et on adore réinventer la roue", qu'est-ce qu'on y gagne ?
[^] # Re: mouais
Posté par JoeltheLion (site web personnel) . Évalué à 5.
Bon, je ne nie pas qu'ils ont pu faire une compression un peu meilleure à qualité visible égale, je leur fait confiance, mais le résultat ne me semble franchement pas justifier "encore un format de plus". Donc, à part, "oui mais celui là c'est *notre* format et on adore réinventer la roue", qu'est-ce qu'on y gagne ?
Un format qui n'est pas encombré par des tonnes de brevets, et avec une implémentation libre disponible, de manière à ce que ça puisse être implémenté rapidement dans tous les navigateurs qui le souhaitent?
[^] # Re: mouais
Posté par ecyrbe . Évalué à 1.
[^] # Re: mouais
Posté par Éric (site web personnel) . Évalué à 2.
Bref, même question, qu'est ce qu'on y gagne ?
[^] # Re: mouais
Posté par JoeltheLion (site web personnel) . Évalué à 3.
[^] # Re: mouais
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: mouais
Posté par yellowiscool . Évalué à 2.
J'espère que le format va rapidement s'imposer dans les logiciels libres tels que les visionneuses d'images, gimp, libreoffice et autre, et aussi sur mac.
Envoyé depuis mon lapin.
[^] # Re: mouais
Posté par Littleboy . Évalué à 4.
C'est du reencodage de JPEG (avec les artefacts du a la compression). Quand on compare a partir d'une source brute, c'est tout de suite beaucoup moins bon.
Ensuite sur la qualite, vous vous rendez compte que c'est du reecondage, donc avec perte (pensez reecondage MP3 -> OGG)? L'image WebP rajoute donc un encodage avec perte par dessus le JPEG. Parler de meilleure qualite, c'est stupide (gain de place par contre oui).
Et on en vient a:
regarde comme le crane du chauve est plus lisse avec webm
C'est parce que VP8 rajoute du flou partout (c'est un des gros problemes d'ailleurs). C'est pas de meilleure qualite, c'est une grosse perte d'information!
On peut aussi appliquer un flou gaussien sur l'image JPEG, ca sera beaucoup plus lisse (= plus beau), par contre niveau textures, ca sera tout pourri. Exactement comme WebP qui arrive a faire moins bien que JPEG niveau textures (oue, la honte) dans certains cas.
[^] # Re: mouais
Posté par Troy McClure (site web personnel) . Évalué à 0.
Par contre ça sent un peu la bidouille chez google, parce que la vignette du chauve, coté jpg c'est:
http://code.google.com/intl/fr-FR/speed/webp/images/2.jpg
et codé webp c'est:
http://code.google.com/intl/fr-FR/speed/webp/images/2_webp.p(...)
donc d'un coté une miniature jpg baveuse, et de l'autre une miniature png , ce n'est pas vraiment fair-play.
[^] # Re: mouais
Posté par CrEv (site web personnel) . Évalué à 4.
pourquoi ?
S'ils veulent que tout le monde voit ce que ça donne, étant donné que tout le monde n'a pas de décodeur WebP il faut bien la convertir dans un format lisible.
Le png étant sans perte, il est donc sensé représenter ce que donnerais un WebP (poids mis à part).
La transfo WebP - png ne devrait rien changer à l'aperçu (ni dans un sens, ni dans l'autre) donc il n'y a rien de non fair-play à mon avis (à moins que tu ai une autre solution de comparaison)
[^] # Re: mouais
Posté par Troy McClure (site web personnel) . Évalué à 2.
A gauche , l'image c'est
JPG original -> converti en miniature -> converti en jpg baveux
à droite:
JPG original -> converti en webp -> converti en miniature -> converti en PNG qui ne bave pas.
Si ils voulaient etre fair-play ils auraient converti les deux miniatures dans le même format, jpg baveux ou png.
[^] # Re: mouais
Posté par jeberger (site web personnel) . Évalué à 3.
A gauche, l'image c'est:
JPG original -> reconverti en JPG
A droite, c'est:
JPG original -> converti en webp -> converti en PNG qui ne change rien mais qui peut être lu par tout le monde.
Cet aspect là de la comparaison est tout à fait honnête. Le vrai problème, comme l'ont dit d'autres personnes, c'est d'être parti d'un JPG au lieu de partir d'une image originale sans perte.
[^] # Re: mouais
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: mouais
Posté par Littleboy . Évalué à 4.
Oui, du coup je comprends :)
Mais bon, moi je commence a avoir l'habitude de l'equipe marketing d'On2 et de leur comparaisons foireuses, donc j'ai ete direct a la source.
Et entre les deux versions, la version webp est floue avec:
- des gros blocs de couleur - en particulier en haut a droite et sur le bleu du maillot
- une perte de texture sur la figure et les bras (le crane est tout lisse, c'est sur :D)
Et je parie que si on partait de la source originale, la version webp serait encore bien pire.
[^] # Re: mouais
Posté par Éric (site web personnel) . Évalué à 3.
Et pour ne rien gâcher le webp final semble avoir gommé des artefacts qui étaient présents à la base dans le rendu jpeg. Pourquoi pas mais ça me semble étrange quand même.
S'ils ont implémenté un format qui compresse une donnée tout en l'améliorant, je dis banco, mais je reste très suspicieux.
Ou alors, si j'en crois l'étude, on parle d'une jpeg d'origine, qui est ramené à un SNR arbitraire d'un côté avec un jpeg, de l'autre avec un webp. Et je ne peux m'empêcher de me demander si là encore il ne pourrait pas y avoir un biais. Le webp entrainant des défauts potentiellement différents du jpeg, l'addition des deux pourrait effectivement être plys sympa qu'une dégradation forte avec un seul type d'artefact. Mais je ne me lancerai pas de perche pour savoir ce qu'il en est avec un format d'origine propre, ou avec un SNR plus élevé, ou si l'image d'origine était un webp (qu'on recompresse d'un côté avec un peu de jpeg, et de l'autre avec un webp plus agressif).
Je me demande aussi si le SNR choisi n'est pas trop bas vis à vis de jpeg, et comment il est calculé.
Et bien entendu je me demande si ce sont des exemples au hasard ou des images dans les 10% les plus favorables (on en trouve peut être autant qui montrent le résultat inverse).
Après on peut aussi se demander pourquoi ce sont des miniatures, si la miniature a été faite avant ou après la compression, si cette opération a tenu compte des différences de format, si dans le cas de webp elle n'a pas eu lieu après la conversion en png, et plein d'autres choses.
Bref, la gallerie n'est en rien pour moi une démonstration (vu que ce sont des morceaux choisis) et c'est même presque elle qui me fait le plus douter du format.
Qu'on me montre le corpus avec les images originales et les traitements appliqués avec les paramètres exacts, reproductibles, automatisés, avec des originaux qui ne sont pas déjà en jpeg, avec un détail sur le calcul du SNR qui semble à l'origine de la comparaison, etc.
Je vais paraitre parano, mais le gain est justement trop excellent alors que d'origine ils partent d'un format qui devrait être dégradé (et c'est bien tout le principe)
[^] # Re: mouais
Posté par Stibb . Évalué à 1.
On voit rien, les photo sont trop petites pour apprécier les différences. Faudrait utiliser des outils de comparaisons, notament PNSR, pour mesure la différence de qualité.
Evidement, il ne faut pas utiliser une source en JPG.
Ensuite, un meilleurs taux de compression ne suffit pas. On s'en contre fiche de gagner 10%, on a tous des connexions ADSL et on télécharge des applets flash bcp plus gros sur les pages web. Des formats de compressions meilleurs que le mp3 existent, mais n'ont jamais percé (sauf AAC) pour le grand public. Celui-ci est stupide et ne change que pour un truc qui marche, apporte quelque chose de vraiment signifiant pour lui, ou corrige un défaut vraiment flagrant (c'est par pour les brevets que le gif a disparu pour le png, mais pour les 256 couleurs et le canal alpha).
Quant au JPEG2000, effectivement personne ne l'utilisent, parce que personne n'a d'intéret à l'utiliser. Qu'apporte-t-il par rapport au jpeg? On veut du sans perte => png. On accepte de la perte => jpeg est tres bien. Le jpeg2000 est utilisé au ciné pour les diffusions du cinéma numériques parce que les constructeurs et diffuseurs veulent avant tout la qualité de diffusion, mais pour le grand publique, le jpeg2000, il n'en veut pas. En tout cas, tant que les constructeurs d'appareil photo et de logiciel de retouche ne le supporteront pas comme le jpeg.
Et croire que sortir un codec image suffit à remplacer des formats existant, c'est ignorer que les images sont retoucher dans des logiciels, affichés dans d'autres, traité, redimensionner. C'est toute la chaine qui doit changer. Et pour force à changer, il faut apporter une VRAI valeur ajouter. Avec les bandes passantes actuelles, gagner 5-10% n'intéresse personne. Si on parlait de 50-60% alors là oui l'intéret serait flagrant.
[^] # Re: mouais
Posté par tiot (site web personnel) . Évalué à 1.
Ce n'est pas parce que la bande passante a un coût marginal nul pour les possesseurs Français de l'ADSL que c'est le cas pour tout le monde.
[^] # Re: mouais
Posté par Stibb . Évalué à 2.
[^] # Re: mouais
Posté par Troy McClure (site web personnel) . Évalué à 1.
ben paye toi des yeux on les voit très bien les differences !
maintenant comme discuté plus haut la comparaison est faite de façon malhonnete donc effectivement c'est du bullshit.
[^] # Re: mouais
Posté par Stibb . Évalué à 1.
Et puis, il faut qu'un test soit reproductible pour etre considéré comme valable, tous les parametres doivent etre donné. Bon, si on est incapable de trouver un test reproductible et inconstestable (ou mieux, plusieurs indépendant), c'est que le format est pourri.
[^] # Re: mouais
Posté par steph1978 . Évalué à 1.
je vois pas de lien vers ta galerie, histoire que l'on puisse vérifier tes dires...
# Performance peu probable
Posté par Bastoon . Évalué à 0.
La majeur partie du temps d'attente se retrouve dans la latence du réseau et non dans le volume de données à télécharger (merci à la fenêtre TCP). Du coup je pense que si l'on destine ce format au Web, on ne doit gagner que réellement 1% du temps d'attente.
Bref de quoi rester au bon vieux JPEG...
[^] # Re: Performance peu probable
Posté par barmic . Évalué à 4.
Sais-tu qu'il existe encore des zones en 56kbps ?
De plus l'arrivé de « l'internet mobile © » fait qu'on peut avoir des débits médiocre et qu'on est facturé à la quantité de données téléchargé. Les images peuvent représenter une très grande quantité des données téléchargées.
Donc la question pourrait être « que dirais-tu de payer 38% moins chère ton abonnement ? »
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Performance peu probable
Posté par Bastoon . Évalué à 0.
[^] # Re: Performance peu probable
Posté par Beurt . Évalué à 3.
????
Google ne s'adresse pas qu'aux français vivant dans de grandes cités. Le monde est vaste et peuplé, et j'aimerai bien que tu nous donnes une référence appuyant tes propos : (soit au moins 3 milliards de personnes, c'est ça ?).
[^] # Re: Performance peu probable
Posté par barmic . Évalué à 2.
D'autre part les malvoyants, les daltoniens et les handicapés ne représentent pas la majeure partie de la population, ce n'est pas pour ça que l'on ne doit pas prendre en compte l'accessibilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Performance peu probable
Posté par steph1978 . Évalué à 4.
mm si le chiffre semble optimiste, rien que 20% serait énorme pour eux.
[^] # Re: Performance peu probable
Posté par Antoine . Évalué à 2.
[^] # Re: Performance peu probable
Posté par Éric (site web personnel) . Évalué à 1.
Et même pour une ADSL, ça peut jouer, parce que ton ADSL est franchement sous utilisée, justement à cause de ta fenetre TCP (même si effectivement ce n'est pas sous ADSL que tu verras les plus grosses différences)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.