(Avertissement habituel: Mozilla est mon employeur. Cependant je n'exprime que mes opinions personelles et je ne travaille pas dans le domaine des formats d'images.)
Ce n'est pas un mystère: il existe une forte pression sur Mozilla pour adopter le format d'images WebP.
Une étude publiée par Google affirme que ce format produit, à qualité égale, des images 30% plus petites que JPEG.
La difficulté se trouve dans la définition du mot «qualité». Il existe un certain nombre de métriques concurrentes pour définir la qualité, qui conduisent à des conclusions très différentes. L'étude publiée publiée par Google utilise une métrique appelée SSIM. Il existe plusieurs variantes de SSIM, et celle utilisée par Google consiste à appliquer SSIM aux canaux R, G, B de l'image pris séparément, puis à prendre la moyenne des trois résultats obtenus.
Mozilla vient de publier sa propre étude sur ce sujet. Cette étude reprend la variante de SSIM utilisée dans l'étude de Google (cette variante est nommée RGB-SSIM dans l'étude de Mozilla) et y adjoint trois autres métriques qui sont bien établies (ont fait l'objet de publications dans des journaux scientifiques à comité de lecture). Ce sont donc quatre métriques différentes qui sont utilisées dans l'étude de Mozilla, et les résultats sont très différents d'une métrique à l'autre.
Dans le cas de la métrique RGB-SSIM que Google avait utilisée, l'étude de Mozilla confirme les résultats de Google sur la supériorité de WebP sur JPEG. Mais les trois autres métriques donnent des résultats différents. Si l'on accorde une importance égale aux quatre métriques utilisées, alors WebP et JPEG sont à égalité. Il semble en tout cas impossible d'affirmer que l'un est supérieur à l'autre en taux de compression, sauf à accorder une très grande importance à une métrique au détriment de toutes les autres.
Alors est-ce que WebP donne des fichiers plus petits que JPEG à qualité égale? Tout dépend de ce qu'on entend par qualité, donc.
Bien entendu, WebP a d'autres avantages sur JPEG. En particulier, WebP offre le support d'un canal alpha, peut aussi servir de format sans perte (comme PNG) et peut contenir une image animée (comme GIF). Ce dernier point cependant est assez controversé: Mozilla considère généralement que les formats d'image animées sont devenus inutiles étant donné que les formats de video sont capables de faire exactement la même chose (on peut faire du «GIF animé» avec WebM!), et il n'existe pas de façon raisonnable de supporter WebP pour les images fixes sans supporter aussi les animations (il n'y aurait pas de moyen raisonnable de détecter le support des WebP animés).
# et alors ?
Posté par Nico C. . Évalué à 10.
Question de neophyte : C'est si compliqué d'integrer un format supplementaire ?
En tout cas, j'ai toujours pensé que le propre du Libre en general (et des nouvelles generations de navigateurs dont Mozilla est le precurseur en particulier) etait de reagir vite et bien aux besoins des utilisateurs et des developpeurs donc je me dis que lorsqu'un nouveau format commence a se rependre, qu'il apporte de nouvelles fonctionnalités non negligeables au dela de la "simple" amelioration de la qualité et qu'il reste compatible juridiquement avec les valeurs du Libre, c'est toujours bon a prendre et a implementer, non ?
J'ai du mal a comprendre se tortillage du cul…
[^] # Re: et alors ?
Posté par Benoit Jacob (site web personnel) . Évalué à 10.
Très bonne question. Oui, c'est assez cher de supporter un format d'images supplémentaire, pour un fabricant de navigateurs. Pour t'en convaincre, parcours les notes de version de Firefox au fil de années qui annoncent la réparation de failles de sécurité dans libpng, libjpeg, libjpeg-turbo et autres bibliothèques utilisées pour supporter les formats existants. Et au-delà des failles de sécurité, il y a tous les autres plantages et autres bugs rapportés au fil du temps sur bugzilla. Maintenant que PNG et JPEG sont des technologies assez matures, le flux de bug ralentit naturellement… jusqu'au prochain format d'images.
C'est aussi cher en termes de complexité pour le développeur Web (comment décider entre deux formats qui font presque la même chose?) et pour l'utilisateur (si je télécharge une image en WebP, comment est-ce que je la partage avec mes amis incapables de l'ouvrir?)
Alors bien sûr, tout le monde s'attend à ce qu'un jour, il y ait un format qui offre des avantages suffisants sur les formats existants pour justifier ces coûts. La question actuelle est de savoir si WebP est ce format.
[^] # Re: et alors ?
Posté par eingousef . Évalué à 10.
C'est pas un peu fini ces vannes sur les utilisateurs de Debian stable ? :o
*splash!*
[^] # Re: et alors ?
Posté par zebra3 . Évalué à 10.
Ça m'a fait sourire, puis je me suis demandé si je pouvais réellement lire du webp en étant sous stable. Et non, ni GNOME 3.4 ni KDE 4.8 ne peuvent. J'ai pas trouvé pour GNOME mais je sais que KDE [peut le lire depuis la 4.10].(https://bugs.kde.org/show_bug.cgi?id=267365)
Finalement c'est pas drôle ta blague :-(
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: et alors ?
Posté par totof2000 . Évalué à 2.
Clairement, ça ce n'est pas le problème de Mozilla et n'est absolument pas un argument contre ledit support.
Le risque est de ne pas anticiper assez vite le tournant, et de perdre des parts de diffusion (donc revenus moindres si on prend en compte le partenariat Mozilla/Google par exemple).
[^] # Re: et alors ?
Posté par Nico C. . Évalué à 4. Dernière modification le 18 octobre 2013 à 11:50.
Ouais mais ce genre de raisonnement conduit a faire un IE6…
Et puis entendre le terme "c'est cher de…" dans la bouche d'un mozilla-man, c'est assez etonnant je trouve. Je crois que Firefox n'aurait JAMAIS existé si ces 3 mots avaient été dit par les 3 ou 4 pionniers qui ont lancé ce projet completement fou…
Ben, le choix de la meilleure techno pour son besoin, c'est un peu le probleme du developpeur web et de tout informaticien en general, non ?
Quant a l'utilisateur final, c'est toujours pareil : il faut bien enclencher le cercle vertueux qqpart sinon personne ne bouge. Et l'Histoire montre que les navigateurs sont un levier considerable pour l'adoption de nouvelles technos/formats en debordant largement du web.
Tout a fait.
Neanmoins, comme personne n'est capable de predire ce qu'il va se passer sur le web dans 1 an, je pense qu'il ne faut pas trop se poser de questions et faire au mieux avec ce qu'on a.
Au dela de ce probleme particulier, je suis un peu triste de voir Mozilla perdre son leadership au profit de Google. Sans parler de PDM (dont je me fous royalement), il fut une epoque et c'est Mozilla qui tracait la voie a suivre pour les autres et c'est Mozilla qu'on regardait quand on parlait d'innovation sur le web. Aujourd'hui, Mozilla fait plus office de vieille mémé fatiguée dont on garde qq logiciels sur un coin de disque dur par nostalgie.
J'ai l'impression que la machine a idée est un peu usée chez Mozilla et ca me desole. Sans compter que je n'arrive toujours pas a comprendre pourquoi ils se dispersent vers les OS pour mobile mais bon…
[^] # Re: et alors ?
Posté par gnujsa . Évalué à 10. Dernière modification le 18 octobre 2013 à 12:19.
Un autre raison qui doit peut-être faire hésiter Mozilla est qu'il existe au moins 4 concurrents aux fonctionnalités similaires;
Moi ça me rappelle les débats (houleux) entre MNG et APNG cette histoire.
Sans compter, qu'hormis pour les compressions extrêmes (>15 ou 20:1), c'est pas mal dur de voire la différence entre chacun, et le bon vieux JPEG.
Reste les fonctionnalités, mais on arrive déjà à faire presque tout avec les formats existants:
JPEGPNGPNG(16 bits, ça dépasse largement les capacités des meilleurs écrans)PNGPNGGIF^W ANPG^W MNG^W WEBM(ouf!)Ensuite, tout le monde n'a pas le processeur dernier cri et des tonnes de RAM, et donc la rapidité de décodage est aussi importante à mon avis. Et là, le JPEG est très bon, mais le PNG est … imbattable! Il est rapide comme l'éclaire et consomme très peu de mémoire. Ce qui peu paraître étrange pour quiconque à déjà essayer d'enregistrer une image au format PNG, qui est une opération plutôt lente. (c'est un des plus lent en enregistrement, mais LE plus rapide en lecture). J'ose pas imaginer la catastrophe si on remplaçait toutes les images PNG que comportent les pages web par des JPEG2000 qui est horriblement lent à décoder.
Pour ceux qui veulent faire leurs propres essais, il y a ces paquets pour Debian (et peut-être d'autres distribs):
libjpeg-progslibjasper-runtimeopenjpeg-tools(autre implémentation)webplibjxr-toolsPar contre pour le paquet pgf c'est autre chose (en rapport avec LaTeX). Il faut le compiler soi-même: http://www.libpgf.org/
J'avoue ne pas trop comprendre l’engouement pour ces formats, qui, à qualité égale ne permettent, au mieux, que de réduire un tout petit peu la taille des fichiers. Surtout si l'on compare les gains en lossless par rapport au vénérable PNG. À la glorieuse époque des modems 33k, 56k, j'aurai compris.
— "oui, mais un jour les écrans afficheront 65535 nuances de gris !"
— "bof, notre œil a déjà bien du mal à en discerner 255, et pour l'édition il existe des formats plus adaptés (TIFF, DNG)"
[^] # Re: et alors ?
Posté par Jean Roc Morreale . Évalué à 5.
Si la différence est minime lorsque le facteur de compression est faible, plus la compression est élevé, plus la différence est marquée. Le principe de fonctionnement du JPEG2000 permet de conserver les détails là où le JPEG devient un pâté de blocs DCT. La nimage qui va bien (jpg, jp2 et original) et un article en bonux.
voila la raison de la lenteur, cette lib n'a jamais été conçue pour la vitesse mais pour servir de référence. La lib openjpeg est sortie en v2 il y a un moment et est beaucoup plus rapide (pas encore au niveau d'une lib proprio telle que kakadu). La lenteur n'est pas du fait du format.
[^] # Re: et alors ?
Posté par gnujsa . Évalué à 4.
C'est vrai, j'ai été un peu sévère pour le JPEG2000. Lorsque l'on compresse, à une très faible qualité, le JPEG2000 réalise un véritable exploit. Là où le JPEG ne donne que quelques carrés de couleur, le JPEG2000 donne une photo certes complètement pourrie et floue, mais encore tout à fait reconnaissable. On peut faire tenir une Léna (floue) dans seulement 2ko ! C'est bluffant, mais quel est l’intérêt, hormis l'exploit ? L'IJG déconseille l'utilisation de la libjpeg à des niveaux de qualité inférieur à 50, et des logiciels comme Gimp ou Photoshop compresse dans les 85-95 par défaut. ImageMagick et cjpeg à 75. Et a ces niveaux, le JPEG2000 n'apporte presque rien en qualité (à la limite le JPEG peut même paraître à certains plus net/de meilleur qualité).
C'est vrai aussi qu'en termes de rapidité il y a de grosse différence entre jasper et d'autres implémentations
Mais ça reste quand même loin derrière PNG. Un test en lossless PNG vs 2 implémentations proprio de JPEG2000 (LuraWave et Kakadu)
http://www.imagecompression.info/gralic/
Compression Decompression
(sec) (sec)
LuraWave 381.56 373.81
Kakadu 312.77 273.03
PNG 844.37 72.62
Ce qui est particulier dans PNG, c'est l'asymétrie entre les temps de compressions et de décompression, ce qui fait qu'il est très léger pour les navigateurs. Et encore il est comparé, là, avec ce qu'il se fait de mieux en codec JPEG2000, pas avec ce que l'on a dans le libre…
Le JPEG2000 ça fait 10 ans que j'en entend parler, il est toujours pas intégré dans la totalité des logiciels que j'utilise, il faut passer par des conversions en lignes de commande, si le fichier est trop gros, ça fait en moitié freezer ma machine, et je vois pas la différence dans les niveaux de compression usuels, alors j'ai fini par perdre espoir. Mais dans le cinéma, il s'est imposé au travers du MJPEG2000.
[^] # Re: et alors ?
Posté par Jean Roc Morreale . Évalué à 3.
Un des intérêts c'est d'avoir un fichier plus petit pour une qualité visuelle égale ou supérieure. Voici quelques fichiers où tu pourras comparer la différence entre un JPEG Q80 de 208ko et un JP2 avec un ratio 1:50 de 84ko. L'échange de photos de chatons étant la base d'internet, cela diviserais par 2 le poids total pour une qualité approchante.
[^] # Re: et alors ?
Posté par Reihar . Évalué à 5. Dernière modification le 18 octobre 2013 à 20:14.
J'ai en ce moment une connexion lente chez moi, c'est passager mais ce n'est pas si rare que ça. La 3g de mon téléphone est lente. La 3g de mes amis et de ma famille est lente. J'ai des amis qui vivent à la campagne et dont la connexion est aussi lente.
Oui, en 2013, l'optimisation en taille est encore pertinente.
[^] # Re: et alors ?
Posté par Reihar . Évalué à 1.
Est-ce qu'un modo peut corriger ma quote foireuse. Seule la première phrase était à citer, le reste étant mon opinion.
[^] # Re: et alors ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Fait.
[^] # Re: et alors ?
Posté par Reihar . Évalué à 1.
Merci.
[^] # Re: et alors ?
Posté par mael . Évalué à 3. Dernière modification le 18 octobre 2013 à 15:34.
Et pas seulement pour le client !
Quelques octets gagnés par-ci, par-là, ça peut être un gain de bande passante énorme pour un site à forte fréquentation. Et la bande passante, ça se paie…
[^] # Re: et alors ?
Posté par ahuillet (site web personnel) . Évalué à 5.
Un autre concurrent intéressant serait H.264 en codage intra (on peut utiliser H.264 pour coder juste une image). H.264 est strictement supérieur à JPEG (moins gros à qualité équivalente, meilleure qualité à taille équivalente), et a l'énorme avantage d'être supporté en hardware sur la plupart des plateformes, contrairement à beaucoup d'autres codecs.
Évidemment, il y a les brevets, mais de ce côté de l'Atlantique on ne devrait pas trop s'en préoccuper.
[^] # Re: et alors ?
Posté par mickabouille . Évalué à 4.
Si j'ai bien compris, on parle de code qui est déjà dans firefox. Oui, celui qui sert à lire les webm.
A moins que tout ajout de fonctionnalité dans mozilla se fasse par copie
de bibliothèquede code sans réutilisation. Dans ce cas, une grosse partie de la maintenance est déjà prise en charge.# Je retourne la question .....
Posté par totof2000 . Évalué à 7.
… Pourquoi ne pas supporter ce format (en dehors d'un manque de ressources à affecter à ce support par rapport à son utilisation réelle) ? Je ne sais pas s'il est très répandu sur le web à ce jour, mais :
- vu que les images sont de qualité équivalente
- vu qu'il permet des choses en plus
- vu que Chrome et Opera le supportent déjà
- vu qu'Androïd (qui est quand même l'OS le plus répandu sur les smartphones) le supporte
n'est-ce pas se tirer une balle dans le pied pour Mozilla de ne pas implémenter ce support ?
Après je sais qu'on ne peut pas tout faire, mais ça risque d'être un problème à terme pour Mozilla s'ils s'entêtent dans leur position. Sinon, pour cette histoire de qualité d'image, il est fort probable que dans certains cas les images JPEG aient un meilleur rendu que les images webp, mais dans ce cas, laissons aux éditeurs de contenu choisir en fonction de l'image et de son rendu le format utilisé: utiliser jpeg lorsquee le rendu sous webp est moins bon, et vice-versa …
[^] # Re: Je retourne la question .....
Posté par Benoit Jacob (site web personnel) . Évalué à 9. Dernière modification le 18 octobre 2013 à 09:12.
Cf ma réponse ci-dessus sur en quoi supporter plus de formats a un coût.
C'est en effet une position difficile, au vu de la pression existante. Il est très possible que Mozilla finisse par supporter WebP non pas pour ses qualités intrinsèques mais simplement en réaction à la pression. En attendant, on espère que l'étude qu'on vient de publier permettra au moins de contribuer des bases techniques saines au débat.
La question est de savoir si les avantages que ça offre justifient les coûts d'une telle décision. C'est pour aider à répondre à cette question que cette étude a été effectuée.
[^] # Re: Je retourne la question .....
Posté par fravashyo (site web personnel) . Évalué à 0.
excuse moi de réponse ça, peut-être que c'est un peu cliché, mais vu que Google semble avoir aidé pas mal Mozilla au niveau financier, est-ce que cela ne serait pas un juste retour des choses de supporter ce format, d'autant plus qu'il y a le risque pour mozilla de voir leurs utilisateurs les délaisser qu'il manque des composants utiles ?
D'autre part, l'étude n'est pas évidente à lire. Pour se rendre compte de la qualité de la compression, ça serait pas mal d'avoir des images montrant les différences. Par exemple pour le webm, dans certains cas, à taille égale la compression fait des artefacts et un aspect flou assez désagréable en comparaison de h264.
Enfin, quid de la charge dans le navigateur d'un format apparemment plus compressé ? Est-ce que ça risque de rendre l'affichage des images plus lourd sur les ordinateurs les moins puissants ?
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Je retourne la question .....
Posté par Benoit Jacob (site web personnel) . Évalué à 6.
Ouille! J'espère que l'avenir du Web ne dépendra jamais de ce genre de petits arrangements entre amis!
Plus généralement, Mozilla et Google sont partenaires sur certains points (par exemple le partenariat qui fait de Google le moteur de recherche par défaut dans Firefox), tout en étant en concurrence directe sur d'autre fronts, et avec des visions parfois très différentes de l'avenir du Web.
Les différences visibles à l'œil nu sont assez subjectives, d'où l'utilisation de métriques «mathématiques» pour départager les formats.
Très bonne question; malheureusement je ne sais absolument pas comment se comparent les différents codecs en termes de coût de décompression! Désolé. C'est une bonne question à poser par exemple sur le fil de discussion sur le Google Group mentionné dans le blog de Mozilla.
[^] # Re: Je retourne la question .....
Posté par eingousef . Évalué à -1.
Trop tard.
HAHAHA
*splash!*
[^] # Re: Je retourne la question .....
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
Oui, c'est sûr, le ver est déjà dans le fruit, mais par un jeu de connivences et d'arrangements stratégiques, mais qu'on souhaite ça en tant qu'utilisateur, c'est quand même assez étrange.
[^] # Re: Je retourne la question .....
Posté par fravashyo (site web personnel) . Évalué à 2.
En tant qu'utilisateur, je souhaite pouvoir utiliser des formats d'images plus pratiques que le jpg, et le webp me semble une bonne possibilité, surtout si on considère la transparence, la compression possible également sans perte et l'animation, ce qui remplacerait jpg, png et gif. Un format vidéo n'est pas toujours pertinent pour l'animation, par exemple dans le cas de pixel art, de sprites pour des jeux etc
Après, si c'est le jpg2000 ou XL qui gagnent, pourquoi pas, mais ces 2 formats sont sortis initialement en tant que formats fermés, et n'ont été ouverts que plus tard.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Je retourne la question .....
Posté par G.bleu (site web personnel) . Évalué à 2.
Partant du principe que jpeg/WebP sont des formats destinés à un utilisateur final pour une utilisation ne nécessitant pas une grande qualité (autrement on utilise forcement un format sans pertes), je trouve l'argumentation de Google pertinente : une image quasiment similaire pour l'oeil humain, mais 30% plus petite.
[^] # Re: Je retourne la question .....
Posté par Benoit Jacob (site web personnel) . Évalué à 6.
Je pense que c'est le point essentiel découvert par l'étude: cet argument de "30%" ne repose sur rien d'autre que le choix arbitraire d'une métrique. On peut donc retourner l'argument en choisissant arbitrairement la métrique qui favorise le plus JPEG contre WebP, avec une marge similaire.
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é. 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.
Ce que je dis ici se repose bien sûr sur l'hypothèse que RGB-SSIM n'est pas plus légitime que les autres métriques utilisées dans l'étude. S'il s'avérait que RGB-SSIM était vraiment à elle seule une représentation fidèle de la qualité des images, et pas les autres métriques, alors oui WebP serait effectivement 30% plus petit à qualité égale. Mais a priori, on a quatre métriques qui donnent des résultats très différents, et RGB-SSIM n'est ni plus ni moins légitime que les trois autres.
[^] # Re: Je retourne la question .....
Posté par FluffyHamster . É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 ??
[^] # Re: Je retourne la question .....
Posté par flagos . Évalué à 7.
Les bench pour comparer la compression d'image ou de vidéos se font justement de plus en plus par des tests subjectifs que par des mesures de distances vis a vis de l'original. En fait, on se rend compte que l'oeil humain accepte mieux certaines images ayant plus de bruit.
L'essentiel pour l'oeil est de ne pas avoir d'effet visuel non naturel comme un effet block par exemple. Au final, tant que l'image est jolie, on peut se permettre d’être un peu plus éloigné de l'image de départ…
Bon par contre le problème c'est qu'organiser des tests subjectifs coûte plus cher et ne permet pas une exacte reproductibilité des résultats.
[^] # Re: Je retourne la question .....
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Ils l'ont fait de façon philanthropique à ton avis ou bien parce qu'ils trouvaient un gros intérêt à ce qu'un navigateur qui possède une bonne grosse part de marché embarque par défaut leur moteur de recherche ?
Je ne vois pas pourquoi Mozilla devrait se sentir redevable de Google au point de privilégier l'implémentation d'une de leur techno, c'est quand même inquiétant ce que ça soulève comme implications de faire ça.
Il faut implémenter WebP si ça vaut le coup, en considérant le plan technique, la pérennité, et l'ouverture du format.
# Hein?
Posté par gnumdk (site web personnel) . Évalué à 5.
Ils sont fous chez Mozilla! J'aimerai bien voir un exemple de «GIF animé» avec WebM qu'on rigole sur le fait que c'est équivalent…
Si le web est rempli de GIF animés extrait de vidéos Youtube, c'est pas juste à cause de Flash… Je vois mal une vidéo en boucle donner le même effet, mais je me trompe peut être…
[^] # Re: Hein?
Posté par claudex . Évalué à 6.
Si je ne me trompe pas, tu peux définir un temps d'affichage pour chaque frame avec WebM et la balise vidéo permet de faire tourner le truc en boucle. Du coup, je ne vois pas bien ce qu'il manque pour remplacer le gif.
« 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: Hein?
Posté par Chris K. . Évalué à 5.
La transparence ?
[^] # Re: Hein?
Posté par fravashyo (site web personnel) . Évalué à 3.
l'édition ultérieure du fichier (image par image, comme dans gimp par exemple) ?
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Hein?
Posté par CrEv (site web personnel) . Évalué à 10.
Il y a quand même une différence entre les deux.
Dans le cas des gif l'information d'animation est contenue uniquement dans l'image, donc ça tourne en boucle tout seul et ça se place partout
Dans le cas d'un WebM et balise vidéo, il faut agir au niveau de la balise, donc de l'intégration du fichier dans la page. C'est pas grand chose, mais ça rajoute un rien de complexité pour rien…
[^] # Re: Hein?
Posté par eingousef . Évalué à -10.
Toi, tu es du genre à trouver que les infographies c'est trop de la balle.
*splash!*
# JPEG2000
Posté par Jean Roc Morreale . Évalué à 5.
Le format jp2k est :
- normalisé depuis plus d'une décennie
- poruvu d'implémentations libres
- utilisé dans des domaines pro exigeants (archives, médecine, géomatique, cinéma)
- beaucoup plus intéressant que le JPEG Baseline (canal alpha,région d'intérêt, meilleure dégradation, etc.)
Est-ce qu'une étude comparative est prévue ? Histoire d'avoir un refus techniquement mieux argumenté que ça ?
[^] # Re: JPEG2000
Posté par Benoit Jacob (site web personnel) . Évalué à 6.
Je pense que la seule raison pour laquelle ce format n'a pas été inclus dans l'étude, est le temps: ça a déjà pris très longtemps de réaliser cette étude, car il y a un grand nombre de pièges à éviter, et la complexité augmente avec le nombre de formats testés. Maintenant que cette première étude a été publiée, je suppose que mes collègues seraient ravis de recevoir des contributions ajoutant JPEG2000 à la liste des formats étudiés, à condition que ça soit fait avec autant de soin que pour les autres formats.
Cf aussi cette réponse sur le fil de discussion «officiel»: https://groups.google.com/d/msg/mozilla.dev.platform/9NKc7OeEFLM/RU3kg-C4UOsJ
JPEG2000 est aussi intéressant en ce qu'il complète le paysage actuel des formats préférés de chaque grand fabriquant de navigateurs:
- Google et Opera supportent WebP;
- Microsoft supporte JPEG -XR;
- Apple supporte JPEG2000.
C'est intéressant parce que ça souligne le fait que même si Mozilla adoptait WebP, il n'est pas du tout évident que Microsoft et Apple suivraient. Dans cette course, chacun (sauf Mozilla pour le moment) a déjà son cheval favori.
[^] # Re: JPEG2000
Posté par Jean Roc Morreale . Évalué à 6.
C'est dommage qu'il n'ai pas été considéré en priorité puisque le support du JPEG2000 est dans les fait déjà présent dans Firefox via PDF.js
[^] # Re: JPEG2000
Posté par zebra3 . Évalué à 9.
Ce que ça souligne surtout, c'est qu'alors qu'au début Mozilla était moteur et poussait le web vers le haut, et ajourd'hui elle se contente d'essayer de suivre les autres et se demande ici lequel suivre pour ne pas être trop à la ramasse…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: JPEG2000
Posté par zebra3 . Évalué à 5.
Surtout que JPEG2000 doit être bien plus répandu que webp…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: JPEG2000
Posté par Wawet76 (site web personnel) . Évalué à 7.
Je me trompe peut-être, mais il me semble que JPEG2000 est un exemple de format qui n'a pas décollé à cause d'histoires de royalties à payer non ?
Il fallait faire comme pour le gif et le mp3 : Laisser tout le monde l'utiliser et attendre un peu avant de venir faire chier.
# Putain de brevets !
Posté par patrick_g (site web personnel) . Évalué à 6.
Dommage qu'à cause des brevet on ne puisse pas choisir HEVC-MSP car il déchire tout dans le test.
Est-ce que JPEG-2000 est implémentable librement sans risques maintenant ?
[^] # Re: Putain de brevets !
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
En effet :-(
Je ne connais pas la réponse à cette question, désolé.
[^] # Re: Putain de brevets !
Posté par Jean Roc Morreale . Évalué à 4.
Jasper est une implémentation officielle de référence publiée en 1999 et sous licence MIT depuis 2004.
Nombre de procès = 0
[^] # Re: Putain de brevets !
Posté par CHP . Évalué à 9.
Ce qui ne signifie pas qu'un procès ne pourrait pas arriver si c'etait plus utilisé
[^] # Re: Putain de brevets !
Posté par Jean Roc Morreale . Évalué à 3.
Je suis prêt à prendre les paris sur les chances de réussite d'un ayant-droit qui aurait laissé utiliser cette lib dans des logiciels commerciaux pendant plus d'une décennie alors qu'elle était directement incluse comme référence officielle dans les standards de ce format. Apparemment le risque de litige n'empêche pas des organismes tel que le CNES de faire développer openjpeg.
Et vu que des formats intégrés par Mozilla tel que le GIF (Unisys) et le JPEG (Forgent Networks) n'ont pas été épargné par ce type d'ennui, ça serait ridicule de s'en servir comme épouvantail pour le JPEG2000. Et c'est sans parler de WebM…
[^] # Re: Putain de brevets !
Posté par gnujsa . Évalué à 4.
moui.. J'ai pas regardé le test en détail, mais en ne considérant que le canal de luminance (le plus important visuellement), et à des taux de compression usuels (réglage "qualité" entre 75 et 90), ça fait en gros du 10% plus petit que le JPEG classique. C'est un tout petit déchirement alors… une égratignure.
La seule métrique vraiment flatteuse c'est celle en RGB, mais elle est à mon avis la plus trompeuse pour plusieurs raisons: les appareils photos, "sous-échantillonnent", dès la prise de vue les canaux R et B (matrice de Bayer: 2 fois moins de pixels rouge et bleu que de vertes), ensuite ils floutent encore un peu pour noyer le bruit, y compris dans les RAW ! (qui ne sont donc plus vraiment RAW, mais chute il faut pas le dire), puis encore une fois dans lors du dé-matriçage et également lors du dé-bruitage toujours beaucoup plus fort sur la chrominance. Et pour finir, les jpeg sont couramment utilisé avec les canaux de chrominances sous-échantillonnés.
Et pour la métrique basée sur le PSNR, et bien c'est même moins bien que le vieux JPEG pour les facteurs de qualité usuel (>75)
Alors, il y a pas de quoi sauter au plafond, je trouve, surtout si en plus il y a des cochonneries de brevets dedans.
Et quelque chose de TRÈS important, et pas indiqué par les tests, est : Es-ce que d'ouvrir une image, par exemple de 10 Mpix, met à genoux un ordinateur de plus de 4/5 ans ? (comme le JPEG2000). Parce que si le but est de remplacer le couple JPEG/PNG, ça veut dire que le web peut rapidement en être farci, et que ça serait bête que l'on soit obligé de racheter des ordinateurs derniers cris, ou de recharger la batterie de son portable tout les 1/4 d'heures, pour aucune amélioration visible …
[^] # Re: Putain de brevets !
Posté par Shuba . Évalué à 4. Dernière modification le 18 octobre 2013 à 13:26.
D'après wikipedia, les brevets des sociétés ayant conçu le JPEG-2000 seraient utilisables sans avoir à payer de royalties.
Traduction:
Du coup de mon point de vue ça a l'air clair, au moins pour le "cœur" du standard. Mais je ne sais pas quelle étendue couvre ce "cœur".
# Gonflé
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ils vont retirer le support d'APNG alors?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gonflé
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
APNG est généralement considéré comme une erreur regrettable, mais le Web est ainsi fait qu'il est difficile de retirer le support d'une technologie supportée dans la version actuelle d'un navigateur. Mais à terme, oui, ce serait une bonne chose.
[^] # Re: Gonflé
Posté par Reihar . Évalué à 3.
En quoi est-ce que c'est une erreur ?
C'est une question sincère et non ironique.
[^] # Re: Gonflé
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Comme dit plus haut, tous les formats d'images animées sont devenus inutiles depuis que la balise
<video>existe. D'autre part, APNG n'a pas à ma connaissance été adopté par d'autre fabricants de navigateurs que Mozilla et Opera, et un standard du Web qui n'est pas largement accepté, c'est toujours dommage: un coût mort pour les navigateurs et les webdevs qui l'ont soutenu. C'est pour ça qu'on fait attention avant de supporter un nouveau format![^] # Re: Gonflé
Posté par Maclag . Évalué à 4.
Procédure pour retirer le bout de code boulet:
-introduire un bug flagrant sur le format dans la prochaine version
-attendre 6 mois
-si aucun rapport de bug n'est reçu, virer la lib
Pom, pom, pom… --------> [ ]
[^] # Re: Gonflé
Posté par zebra3 . Évalué à 4.
Ce qui n'a pas empêché Mozilla de virer le support de Gopher. Certes il n'était pas très utilisé, mais perso je n'ai jamais vu d'image APNG (sur un site web ou ailleurs)…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gonflé
Posté par totof2000 . Évalué à 2.
Quel est l'intérêt ?
# Qualité empirique
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 5.
On voit des différences à l'œil nu ? par-ce que je m'en tamponne un peu le coquillage de savoir qui a la plus grosse métrique si je sens pas la différence.
Ça pourrait être un sondage avec des tailles de fichiers identique en demandant quelle photo est la plus proche de l'original par exemple.
[^] # Re: Qualité empirique
Posté par gnujsa . Évalué à 3.
Tu a complètement raison, mais c'est beaucoup plus facile de faire un calcul mathématique que de mettre en place un sondage, alors on s'en contente même si la métrique ne veut rien dire, ou pire si elle est trompeuse.
Par exemple la plupart des tests effectués sur les valeurs de bruits des appareils photos numériques sont basés sur l'écart-type calculé pixel à pixel. Le calcul est d'une simplicité enfantine, et ça donne un chiffre comparable, même s'il ne représente rien du tout. Un teste simple est de prendre une photo bruitée et de la flouter légèrement d'un flou gaussien. L'écart-type entre chaque pixel va bien chuter, et la métrique correspondante (SNR en dB) va augmenter, mais la photo ne sera pas meilleur. Elle sera moins nette d'une part, mais même son bruit ne disparaîtra pas. Il sera simplement étalé vers les basses fréquences ou justement l’œil est très sensible. Ça fera passer le bruit de type grain, à un bruit, encore plus moche, de type tache floue. Mais on aura en contre-partie beaucoup plus de décibel à annoncer sur la fiche technique …
Les techniques de calcule utilisées sur le site de Mozilla (type SSIM) sont censées remédier à ce problème et mesurer mathématiquement une impression visuel (!) Mais elles comportent d'autre biais. La technique du sondage de type JND (just-noticeable differences, seuil à partir duquel 50% des observateurs constate une différence) serait bien meilleure.
Kodak dans les années 90 utilisait ce système pour mesurer la granularité de ses films (le Print Grain Index)
# Petite précision
Posté par flagos . Évalué à 10. Dernière modification le 18 octobre 2013 à 14:38.
Attention à ce raccourci, on le lit fréquemment. Une norme en compression d'images ou de vidéos documente généralement le décodage. Il s'agit d'une suite d'outils qu'un encodeur choisit ou non d'utiliser. L'essentiel, c'est que le stream qui sort de l'encodeur soit décodable par un décodeur.
Ainsi, selon son implémentation, deux encodeurs de la même norme ne produiront absolument pas le même fichier en sortie. D'ailleurs, on comprend aisément qu'un encodeur avec une contrainte temps réél ne puisse pas atteindre la même qualité d'image qu'un encodeur qui passe plusieurs heures a faire son calcul. C'est d'ailleurs pour cela qu'on parle de la qualité d'un encodeur (ce qui n'aurait aucun sens si l'encodage était entierement normé).
Donc au final, cette étude compare une implémentation d'encodeur jpeg vs une implémentation de webp (et l'étude les précise bien). Et ca me parait super important de garder cette précision en tête.
# Laisser les utilisateurs décider ?
Posté par TilK . Évalué à 0.
Comme dit précédemment, ne serait-il pas plus intéressant de laisser les utilisateurs choisir le format d'images qu'ils préfèrent ?
Ne pourront pas organiser un sondage en aveugle sur le site de Mozilla pour évaluer la qualité ressentie par les utilisateurs ?
On affiche une image "haute qualité" (plusieurs types d'images proposés : photos, graphiques…) et des versions fortement compressés avec les différents codecs mais avec une taille du fichier identique. On laisse les gens noter chaque image à la façon d'un MOS (note de 0 à 5).
Par contre dans l'analyse, l'aspect taille des fichiers n'est peut être pas le plus important pour l'utilisateur final (mais plus pour les sites web). Les premières question qui me viennent à l'esprit sont par exemple les suivantes : Quelle est la vitesse d'affichage de l'image ? Quelle est sa consommation mémoire ? Est-il possible d'avoir une preview de l'image le temps que celle-ci soit entièrement téléchargée/décodée ?
# La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par Benbben . Évalué à 2.
WebP est supporté par les produits googles (normal) :
- Chrome (et sa version libre Chromium) a été le premier navigateur Web à supporter nativement le format WebP8, suivi ensuite par Opera9.
- Android supporte nativement le format WebP à partir de la version Android Ice Cream Sandwich (4.0)12, de ce fait les navigateurs utilisant l'API système, comme Android browser (« Internet »), Chrome Mobile, Zirco Browser, Dolphin Browser Navigateur contextuel des Samsung Galaxy Note.
Le terminal mobile étant l'avenir de la consultation du web, et le poids lourd sur ce secteur étant google. Combien pèse au final la fondation mozilla pour ou contre l'adoption d'un format de fichier comme standard de fait sur mobile et par ricochet sur l'ensemble des plateformes de consultation du Web ?
[^] # Re: La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par zebra3 . Évalué à 5.
Notons tout de même que malgré toute la puissance de Google, VP8 n'a pas vraiment percé. En quoi cela serait-il différent avec webp ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par Benbben . Évalué à 2.
Disons que la puissance n'est rien sans contrôle !
Mais que se passerait-il si le format de l’appareil photo des téléphone androïd passait à webp par défaut ?
[^] # Re: La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par zebra3 . Évalué à 10. Dernière modification le 18 octobre 2013 à 17:29.
Simple : la plupart des gens râlerait parce que leur PC sous Windows ne parvient pas à lire leurs photos, et tu aurais pleins de tutoriaux ou de hacks sur le Play Store pour forcer Android à enregistrer en JPEG comme avant.
Et qui serait emmerdé ? Nous, « parce qu'on s'y connaît en ordinateurs ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par Maclag . Évalué à 4.
Si on ne peut pas les regarder sur l'ordinateur de Tante Jeannine, on demandera au petit cousin qui dira, au choix:
-c'est parce que l'ordinateur de Tante Jeannine est trop vieux, il en faut un neuf (avec une grosse nVidia dedans pour
quand le p'tit cousin vient jouer le week-endque Tante Jeannine puisse mieux voir le web, surtout dans le noir)-c'est parce que le téléphone est bogué, il faut le rapporter au magasin et le faire changer!
Moi je ferais gaffe avant de passer en force sur un truc un peu technique!
[^] # Re: La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par Buf (Mastodon) . Évalué à 1.
Pour le moment, c'est encore largement Apple (source : les statistiques de fréquentations des différents sites web hébergés par ma boite, iOS représente en moyenne 2 fois plus de visites qu'Android), et Safari ne supporte pas WebP. Donc pas d'urgence de ce côté-là.
[^] # Re: La vraie question est plutôt Mozilla pourra-t'il ignorer ce format longtemps ?
Posté par Benbben . Évalué à 1.
ah oui j'avais oublié que la marque à la pomme existait, c'est ça d'être AOSP addict !
# Compression fractale
Posté par Guillaume D. . Évalué à 1.
Il n'y a que la compression fractale qui puisse nous faire faire un bon.
les +
Implémentation libre
fort taux de compression
décompression triviale
les -
pas de standard
long temps de compression
info : http://www.linuxjournal.com/node/4367/print
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.