En d'autres termes, si tu veux des images 30% plus petites que test JPEGs actuels avec une qualité quasiment similaire, c'est très simple: garde JPEG et choisis un degré de compression plus élevé.
Je trouve cet argument très étrange. Les 30% sont gagnés alors que la différence de qualité est franchement dur à voir au premier abord. En zoomant on est d'accord que l'image est moins bonne, mais si je devais quantifier la différence je dirai 5% (à l’œil justement).
Par contre en prenant le même jpeg et en augmentant la compression de 30% ou plus pour arriver à la même taille qu'un webp, le résultat est clair : j'ai perdu 30% de qualité voir plus et l'image commence à être bien dégueulasse.
Maintenant pourquoi utilise-t-on du jpeg sur internet ? Pour le gain de place !
Le jpeg massacre déjà la qualité des images par rapport à un png, c'est un fait. Le saut entre png > jpeg est bien plus important (et déjà irréversible) que entre jpeg > webp par exemple. Est il souhaitable d'aller un peu plus loin en perte de qualité pour gagner significativement en taille de fichier ? Je pense que oui, ça reste dans l'esprit du jpeg et des méthodes de compressions "avec pertes".
WebP ne génère des images plus petites que JPEG que parce que le choix par défaut de niveau de compression est plus agressif.
C'est faux ou en tout cas inexact. Le webp est basé sur exactement les mêmes technos que le jpeg, mais dispose de plus "d'astuces" dans son sac. On a au moins deux grosses évolutions : les intra-prédictions (d'ou la perte de qualité supérieur mais aussi le bond en compression par rapport au jpeg) et la compression arithmétique. Sur le papier, le format est supérieur. Tout comme le h265 est supérieur au h264, le h264 supérieur au vp8, le aac supérieur au mp3...
La qualité des encodeurs peut varier, elle peut être amener à évoluer d'un coté ou de l'autre, mais une des deux technologies est supérieur. Faire appel à des tonnes de métriques mathématiques orientera peut être l'opinion d'un coté ou de l'autre (plus le fait que webp, ben c'est google) mais ne changera pas grand chose au fond du problème.
Et j'avoue que l'argument des rapports de bugs potentiels ne me satisfait pas. En tentant de remplacer flash par shumway (exploit technique en passant), ne vous attendez vous pas ici à une (vrai) vague de rapports de bugs ??
[^] # Re: Je retourne la question .....
Posté par FluffyHamster . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 2. Dernière modification le 18 octobre 2013 à 16:16.
Je trouve cet argument très étrange. Les 30% sont gagnés alors que la différence de qualité est franchement dur à voir au premier abord. En zoomant on est d'accord que l'image est moins bonne, mais si je devais quantifier la différence je dirai 5% (à l’œil justement).
Par contre en prenant le même jpeg et en augmentant la compression de 30% ou plus pour arriver à la même taille qu'un webp, le résultat est clair : j'ai perdu 30% de qualité voir plus et l'image commence à être bien dégueulasse.
Cette page illustre quand même bien le propos : https://developers.google.com/speed/webp/gallery1#samples
Maintenant pourquoi utilise-t-on du jpeg sur internet ? Pour le gain de place !
Le jpeg massacre déjà la qualité des images par rapport à un png, c'est un fait. Le saut entre png > jpeg est bien plus important (et déjà irréversible) que entre jpeg > webp par exemple. Est il souhaitable d'aller un peu plus loin en perte de qualité pour gagner significativement en taille de fichier ? Je pense que oui, ça reste dans l'esprit du jpeg et des méthodes de compressions "avec pertes".
C'est faux ou en tout cas inexact. Le webp est basé sur exactement les mêmes technos que le jpeg, mais dispose de plus "d'astuces" dans son sac. On a au moins deux grosses évolutions : les intra-prédictions (d'ou la perte de qualité supérieur mais aussi le bond en compression par rapport au jpeg) et la compression arithmétique. Sur le papier, le format est supérieur. Tout comme le h265 est supérieur au h264, le h264 supérieur au vp8, le aac supérieur au mp3...
La qualité des encodeurs peut varier, elle peut être amener à évoluer d'un coté ou de l'autre, mais une des deux technologies est supérieur. Faire appel à des tonnes de métriques mathématiques orientera peut être l'opinion d'un coté ou de l'autre (plus le fait que webp, ben c'est google) mais ne changera pas grand chose au fond du problème.
Et j'avoue que l'argument des rapports de bugs potentiels ne me satisfait pas. En tentant de remplacer flash par shumway (exploit technique en passant), ne vous attendez vous pas ici à une (vrai) vague de rapports de bugs ??