Audiovisuel WebP, le format d'image libre de Google

Posté par . Modéré par Bruno Michel.
37
1
oct.
2010
Audiovisuel
Après le WebM, Google s'attaque au format d'image et introduit le WebP, qui produirait des fichiers 39 % plus petits en taille que les autres formats que l'on rencontre sur le Web. Le WebP est particulièrement performant avec des images de petites tailles, que l'on rencontre surtout lors des consultations de sites Web.

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.
  • # P ?

    Posté par (page perso) . Évalué à  9 .

    Je suppose que c'est P pour Porn ?

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: P ?

      Posté par . Évalué à  8 .

      Logiquement ce serait pour « Picture », tout comme « Movie » pour WebM.
  • # JPEG2000

    Posté par (page perso) . Évalué à  5 .

    > Il y a bien eu JPEG 2000, mais il n'a jamais vraiment percé

    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 (page perso) . Évalué à  1 .

      Ça me fait penser au format que Microsoft nous a sorti, en 2006, pour la photo numérique : Le "Windows Media Photo". Après l'annonce de sortie, j'en ai plus entendu parler... Quelqu'un a des retours ?
      Google me dit que ça s'appelle "JPEG XR" maintenant. Mais toujours pas plus entendu parler...
    • [^] # Re: JPEG2000

      Posté par (page perso) . Évalué à  1 .

      D'ailleurs est-ce que quelqu'un a une idée de pourquoi il n'a pas percé sur le web ?
      • [^] # Re: JPEG2000

        Posté par (page perso) . Évalué à  2 .

        Je ne suis pas spécialiste, mais peut-être à cause des licences à payer. Il y a bien une partie sans "brevet/licence", mais si l'on se limite a celle-ci, l'intérêt du format est sans doute limité...
        • [^] # Re: JPEG2000

          Posté par (page perso) . Évalué à  2 .

          Je pencherais plutôt pour un effort d'encoding/decoding plus "chiant" sur le JPEG2000 (aka "ca demande plus de CPU")
          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 (page perso) . Évalué à  4 .

            De plus le GIF et le MP3 l'étaient aussi, cela n'a pas empêché de se faire une solide place au soleil.

            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 (page perso) . Évalué à  4 .

              'il est nettement supérieur sur tous les points

              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 (page perso) . Évalué à  5 .

                MNG?
                • [^] # Re: JPEG2000

                  Posté par . Évalué à  5 .

                  Spec datant de 2001. Implemente par... Konqueror (et rien d'autre a part des plugins pour IE et Opera sans signe de vie depuis quelques annees).

                  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 . Évalué à  2 .

                Je ne crois pas que quelque chose d'autre va prendre sa place, car si ca doit aller sur le web, alors SVG et Canvas vont être utilises. Ils vont être très bien pris en charge par tous les navigateurs majeurs dans un futur très proche.

                Pour tout le reste GIF sera encore utilisé mais les utilisations qui restent semblent plus marginale.
            • [^] # Re: JPEG2000

              Posté par (page perso) . Évalué à  2 .

              Si il n'est pas supporté par IE, il n'a aucun avenir (dommage, parce que je sens que les autres acteurs du secteur sont plus ouverts à supporter de nouveaux formats, à part peut-être Apple/Safari).
              • [^] # Re: JPEG2000

                Posté par (page perso) . Évalué à  1 .

                Je ne pense pas. Contrairement aux vidéos, les images ne coûtent pas trop cher à stocker et il est facile de les avoir en double, dans un format moderne pour les navigateurs modernes, et dans un vieux format pour Windows Internet Explorer.

                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 . Évalué à  3 .

                  > Je verrais bien fleurir des sites web plein de photos, avec une note «
                  > 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 (page perso) . Évalué à  2 .

            Je me disais que justement, si personne ne l'a implémenté en libre (et diffusé), ça doit être un problème de licence. Dans le cas contraire, je suis étonné de ne pas le voir plus...
            • [^] # Re: JPEG2000

              Posté par . Évalué à  1 .

              Vous y etes pas, la raison qui fait que le jpeg2k , le jpeg XR n'ont pas percé (et qui fait aussi que le webP ne perceras pas) est tout autre:

              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 . Évalué à  1 .

                Oula
                s/mansion/mention/
                • [^] # Re: JPEG2000

                  Posté par . Évalué à  1 .

                  Je suis nul en francais et je le sais. Je devrais le mettre dans ma signature d'ailleurs.
  • # « fait avec amour » ?

    Posté par . Évalué à  1 .

    J'ai pas compris l'allusion à propos de l'article de Wikipedia.
  • # Comparatif

    Posté par . Évalué à  3 .

    J'ai ajouté un petit comparatif sur la page wikipedia pour visualiser la différence entre le jpeg et le WebP.
    • [^] # Re: Comparatif

      Posté par . Évalué à  5 .

      J'ai été voir l'image en question et je ne comprends pas bien. L'image enregistrée au format WebP à le même poids que le Jpeg et je ne vois aucune différence de qualité....
      • [^] # Re: Comparatif

        Posté par (page perso) . Évalué à  3 .

        Je me suis dit exactement le même chose...Pas très représentatif de "l'avancée" en question ;). En même temps le jpg qualité 45% (je suppose que c'est ce que veut dire le Q45), normalement c'est vraiment dégueux, et là l'image est nickel...Je suppose qu'il y'a eu erreur (heure tardive d'upload toussa)
        • [^] # Re: Comparatif

          Posté par . Évalué à  1 .

          l'image est pas très représentative je pense. si vous regardez bien le dégradé du fond, vous verrez des carrés pas beaux. mais ça saute pas aux yeux sur cette image. sur d'autres exemples ça pourrait être beaucoup plus flagrant je pense.
      • [^] # Re: Comparatif

        Posté par . Évalué à  1 .

        Je pensais que Q45 signifie qualité 45% (ou 0.45) pour le JPEG. Seulement je ne vois pas les artefacts classiques du JPEG fortement compressé.

        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 . Évalué à  1 .

          Alors je vais détailler la procédure.

          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 (page perso) . Évalué à  -1 .

        Si, il y en a bien une. Il faut cliquer sur l'image et la mettre en taille réelle pour le constater.

        Le webp est d'une qualité égale au png, et le jpg légèrement inférieur.
        • [^] # Re: Comparatif

          Posté par (page perso) . Évalué à  2 .

          C'est quand même subtil... (en gros, je ne vois pas la différence. SI on me donnais les deux images en me demandant de dire qui est qui, j'en serais bien incapable).

          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 (page perso) . Évalué à  4 .

          Bullshit !

          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 (page perso) . Évalué à  5 .

            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.

            Rien n'empêche de développer un RAW directement en PNG…
            • [^] # Re: Comparatif

              Posté par (page perso) . Évalué à  1 .

              Certes. Est-ce que c'est ça qui a été fait ? aucune idée, je demande des précisions. En l'attente je me permets de douter respectueusement.

              En tout cas le webp de qualité équivalente au png, je maintiens, bullshit (ou foutaises, comme tu préfères)
    • [^] # Re: Comparatif

      Posté par . Évalué à  9 .

      Ben je ne sais pas si il est probant.
      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 . Évalué à  4 .

        Fais gaffe, tu t’es mis un u dans l’œil !
      • [^] # Re: Comparatif

        Posté par . Évalué à  2 .

        un diff ne veut absolument rien dire sur la qualité visuel de l'oeil.

        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 liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

    • [^] # Re: Comparatif

      Posté par (page perso) . Évalué à  1 .

      Il eut été intéressant de comparer aussi avec JPEG 2000.
  • # Une analyse exterieure

    Posté par . Évalué à  10 .

    Un test par Dark Shikari (un des dev x264):
    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 (page perso) . Évalué à  2 .

      J'aime bien les posts de Dark Shikari parce qu'ils sont techniques et que c'est toujours intéressant...mais il ne faut pas oublier que c'est le dev de x264 et qu'il défend son beefsteak en critiquant WebM/WebP.

      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 . Évalué à  7 .

        Par exemple dans l'article que tu pointes il y a un mensonge gros comme une maison:

        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 (page perso) . Évalué à  4 .

          Premisse majeure : Dark Shikari dit qu'il n'y a pas l'alpha ni d'autres trucs et que Google n'a pas l'intention d'ajouter aucun de ces trucs (any of these features).

          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 . Évalué à  2 .

            Ben moi je lisais le "any" comme se referant au chroma upsampling et uniquement ca (comme toute personne ayant lu l'annonce Google sait que l'alpha va etre implemente un jour - meme si pour l'instant c'est du vaporware).

            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 . Évalué à  3 .

        x264 concurrent de WebP ?
        • [^] # Re: Une analyse exterieure

          Posté par (page perso) . Évalué à  4 .

          Ce sont les même techniques que WebM, critiquer WebP revient à critiquer WebM.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Une analyse exterieure

        Posté par (page perso) . Évalué à  8 .

        Juste pour préciser que Dark Shikari, en plus de développer x264, est l'un des principaux développeurs de l'implémentation de VP8 dans ffmpeg. Il est sûrement un peu biaisé mais connaît très bien le sujet.
    • [^] # Re: Une analyse exterieure

      Posté par . Évalué à  3 .

      > apres JPEG2000 et JPEG-XR qui n'ont jamais decole sur le web [...], ils s'attaquent a gros

      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 (page perso) . Évalué à  -3 .

    Ne sommes nous donc pas capables de faire des fichiers image de faible poids sans pour autant les saccager ?

    Enfin, c'est un format fait pour visualiser des images, par pour les retravailler, il ne remplacera pas le PNG.
    • [^] # Re: Encore de la compression avec perte ?

      Posté par . Évalué à  3 .

      Si on ne veut pas dégrader une image on utilise un algorithme de compression sans perte. C'est ce que fait le PNG qui utilise LZW il me semble.

      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.
      Évidement on utilise pas de formats compressés pour enregistrer des images que l'on doit retravailler.
      • [^] # Re: Encore de la compression avec perte ?

        Posté par (page perso) . Évalué à  10 .

        C'est surtout que le PNG n'est pas destructeur, donc pour une photographie on arrive vite à des sommets au niveau de la taille par rapport à un simple jpg. Par contre pour les icônes et les formes simples ça fonctionne très bien.
        Bref le PNG est un concurrent du gif pas du jpeg.
      • [^] # Re: Encore de la compression avec perte ?

        Posté par (page perso) . Évalué à  1 .

        C'est ce que fait le PNG qui utilise LZW il me semble.

        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 (page perso) . Évalué à  6 .

      Ne sommes nous donc pas capables de faire des fichiers image de faible poids sans pour autant les saccager ?

      Tu as entendu parler de l'entropie de Shannon ?
    • [^] # Re: Encore de la compression avec perte ?

      Posté par (page perso) . Évalué à  4 .

      Si si, essaye le carré blanc sur fond blanc ;-)

      ⚓ À g'Auch TOUTE! http://agauch.fr

  • # Libre !

    Posté par . É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 (page perso) . Évalué à  10 .

    Alors je récapépète :

    - 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 (page perso) . É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 . Évalué à  1 .

        Il n'y a plus de brevets sur le format JPEG. Depuis 2007, les 20 ans se sont écoulées sur la possibilité de demander quoi que ce soit sur ce brevet. De plus en 2012, plus personne ne pourra réclamer la moindre chose au format JPEG, puisqu'il a été officiellement normalisé en 1992.
      • [^] # Re: mouais

        Posté par (page perso) . Évalué à  2 .

        Euh, tu sous entends que le jpeg qu'on utilise est encombré par des tonnes de brevets, sans implémentation libre disponible, ou qu'il n'est pas implémenté dans tous les navigateurs qui le souhaitent ? parce qu'à mon avis tu dois te tromper quelque part.

        Bref, même question, qu'est ce qu'on y gagne ?
        • [^] # Re: mouais

          Posté par (page perso) . Évalué à  3 .

          Je parlais du JPEG2000, par exemple. Entre ce format et le jpeg à l'ancienne, on doit gagner pas loin d'un facteur deux en taille à qualité identique, ce qui est loin d'être négligeable quand tu es un site qui paye sa bande passante...
    • [^] # Re: mouais

      Posté par (page perso) . Évalué à  3 .

      Tu es allé voir la gallerie ? http://code.google.com/intl/fr-FR/speed/webp/gallery.html je trouve que le gain est incontestable dans ces exemples, aussi bien en taille de l'image qu'en qualité (regarde comme le crane du chauve est plus lisse avec webm)
      • [^] # Re: mouais

        Posté par (page perso) . Évalué à  2 .

        C'est vraiment impressionnant. J'étais septique en lisant les critiques, mais c'est vraiment de meilleure qualité.

        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 . Évalué à  4 .

        je trouve que le gain est incontestable dans ces exemples, aussi bien en taille de l'image qu'en qualité

        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 (page perso) . Évalué à  0 .

          Je pensais que l'original était en png, et naivement je me suis fié aux images affichées dans http://code.google.com/intl/fr-FR/speed/webp/gallery.html , et là tu ne peux pas me dire que tu preferes la version jpg du chauve.

          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 (page perso) . Évalué à  4 .

            > donc d'un coté une miniature jpg baveuse, et de l'autre une miniature png , ce n'est pas vraiment fair-play.

            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 (page perso) . Évalué à  2 .

              Bon j'ai pas été clair:

              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 (page perso) . Évalué à  3 .

                Non.

                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 (page perso) . Évalué à  3 .

                  Et pourquoi est-ce que tu as viré cette étape de redimensionnement que j'indiquais dans mon post ? c'est justement elle qui fait que la comparaison n'est pas honnête.
          • [^] # Re: mouais

            Posté par . Évalué à  4 .

            Je pensais que l'original était en png, et naivement je me suis fié aux images affichées

            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 (page perso) . Évalué à  3 .

        La gallerie j'ai quelques remarques. Déjà on réencode à partir du jpeg, ce qui introduit un biais franchement évident à la base.

        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 . Évalué à  1 .

        Bullshit.

        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 (page perso) . Évalué à  1 .

          On s'en contre fiche de gagner 10%, on a tous des connexions ADSL

          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 . Évalué à  2 .

            théorie des gaz parfait. Gagne 10% et tes webmasters rajouteront 10% de flash/autre connerie en plus.
        • [^] # Re: mouais

          Posté par (page perso) . Évalué à  1 .

          On voit rien, les photo sont trop petites pour apprécier les différences.

          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 . Évalué à  1 .

            attend, les images sont toutes petites! il faut des crop à 100%.

            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 . Évalué à  1 .

      > je sais faire aussi hein

      je vois pas de lien vers ta galerie, histoire que l'on puisse vérifier tes dires...
  • # Performance peu probable

    Posté par . Évalué à  0 .

    Une optimisation de 38% en moyenne, c'est bien mais c'est tellement peu que ça ne percera jamais.
    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 . Évalué à  4 .

      Toi tu as l'ADSL en illimité.

      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 ? »

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: Performance peu probable

        Posté par . Évalué à  0 .

        Tu as raison j'ai bien de l'ADSL avec data illimité. Mais cela représente la majeur partie de la population, voilà pourquoi je ne crois pas à un renversement.
        • [^] # Re: Performance peu probable

          Posté par . Évalué à  3 .

          Tu as raison j'ai bien de l'ADSL avec data illimité. Mais cela représente la majeur partie de la population, voilà pourquoi je ne crois pas à un renversement.

          ????

          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 : cela représente la majeur partie de la population (soit au moins 3 milliards de personnes, c'est ça ?).
        • [^] # Re: Performance peu probable

          Posté par . Évalué à  2 .

          Le marché de l'« internet mobile » explose. Des départements comme l'Ardèche sont très mal couverts par l'ADSL, mais il y a aussi des pays entiers qui sont dans cette situation.

          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é.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Performance peu probable

      Posté par . Évalué à  4 .

      beaucoup de fournisseurs de contenu seraient ravis de diminuer leur bande passante de 39%.
      mm si le chiffre semble optimiste, rien que 20% serait énorme pour eux.
      • [^] # Re: Performance peu probable

        Posté par . Évalué à  2 .

        Vu l'utilisation massive des Youtube & co, je doute que la majeure partie de la BP soit composée de JPEGs...
    • [^] # Re: Performance peu probable

      Posté par (page perso) . Évalué à  1 .

      Wifi pourri, connexions par téléphone mobile, ben 30% sur la totalité des images (qui représentent au moins de 30 à 50% du poids total des sites) ça n'est pas négligeable.

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.