Journal WebP, le format d'images ultime

Posté par (page perso) . Licence CC by-sa
60
24
nov.
2011

Sommaire

WebP est un format d'image matricielle conçu par Google à partir du format des images inter-trame du format vidéo VP8 qui sert lui-même de base au format multimédia WebM.

À ma connaissance, le format WebP n'est pas encore finalisé, et Google ajoute d'ailleurs régulièrement de nouvelles fonctionnalités. La vocation de WebP est, à terme, de fournir un remplacement avantageux aux trois formats couramment utilisés sur le Web : JPEG, PNG et GIF.

Formats existants

 JPEG

JPEG est un format compressé avec pertes, particulièrement adapté aux photographies et inadapté aux dessins comportant des aplats, qui sont mal compressés et fortement dégradés.

Le principal inconvénient de JPEG est donc sa faible performance au regard de ce que permettent les connaissance actuelles. Un inconvénient plus secondaire est son absence complète de prise en charge de la transparence éventuelle d'une image, qui est souhaitable lorsque l'on souhaite ne conserver que l'objet principal d'une photographie.

 PNG

PNG est un format compressé sans pertes, particulièrement adapté aux dessins comportant des aplats et inadapté aux photographies qui sont très mal compressées.

PNG a peu d'inconvénients pour peu que l'on prépare les images convenablement. Il prend par ailleurs en charge la transparence au moyen d'un canal alpha, totale ou partielle, c'est-à-dire que des points de l'image peuvent être opaques, transparents ou translucides à un degré variable.

Il existe une variante animée de PNG, peu répandue et peu prise en charge.

GIF

GIF est un vieux format compressé sans pertes, également indiqué pour les dessins comportant des aplats et inadapté aux photographies.

Le principal inconvénient de GIF est qu'il utilise une palette qui ne permet de représenter que 256 couleurs dans une image, quoique ces couleurs puissent être choisies librement dans la gamme usuelle de 24 bits. GIF a également longtemps été sujet à des brevets qui ont conduit à son abandon progressif en faveur de PNG.

En revanche, l'intérêt principal de GIF est qu'il est largement pris en charge et permet de définir des animations utilisant plusieurs images, chacune pouvant être affichée pendant un temps réglable.

 Le format WebP

Compte tenu des dernières améliorations de WebP, voici les fonctionnalités principales de ce format.

 Compression avec pertes

WebP étant basé sur le format vidéo VP8, sa fonctionnalité principale est la compression avec pertes, avec une efficacité qui le classe parmi les meilleurs codecs existants. Comparé à JPEG, WebP permet de réduire le poids d'une image d'environ 30% pour une qualité identique.

 Compression sans pertes

WebP fournit depuis le 18 novembre un mode de compression sans perte. Comparé à PNG, WebP permet de réduire le poids d'une image d'environ 28%, la qualité étant nécessairement identique étant donné que ces formats ne dégradent pas l'image.

 Transparence

WebP permet depuis cette même date de coder la transparence d'une image dans un canal alpha, qui peut être compressé avec ou sans perte indépendamment des canaux de couleur.

La possibilité de compresser sans pertes le canal alpha d'un objet photographié avec pertes est intéressante, dans la mesure ou les informations de transparence ont une nature bien différente des informations de couleur, et sont caractérisées par des aplats entièrement transparents et entièrement opaques à l'exception des seuls contours.

 Animation

WebP propose depuis le 3 octobre de définir des animations composées de plusieurs images avec une chronologie arbitraire semblable à ce que propose GIF.

L'intérêt de ce format d'animation est qu'il ne souffre pas des inconvénients de GIF, et qu'il permet par ailleurs d'utiliser au besoin une compression avec pertes.

Conclusion

WebP prend en charge les fonctionnalités de tous les formats courants actuellement utilisés, avec des performances supérieures : techniquement, il peut déjà les remplacer avantageusement. Il est également intéressant de disposer d'un format unique adapté à tout type d'image matricielle, qui peut éviter aux béotiens de s'interroger — et de se tromper — sur le format approprié.

WebP fournit également des fonctionnalités supplémentaires, telles que la transparence sur les images avec pertes ou les animations avec pertes. Ces fonctionnalités comblent des manques réels et fournissent donc un intérêt intrinsèque à ce nouveau format hors de la recherche de la simple performance.

WebP est notamment pris en charge par les navigateurs Web Chrom{ium,e} et Opera, ainsi que par la boîte à outils ImageMagick. Il reste en revanche beaucoup d'efforts à faire pour donner à ce format une chance de s'imposer comme cela a été fait pour WebM. La résistance au changement devrait d'ailleurs être supérieure à celle qui existe dans le domaine de la vidéo, dans la mesure où les images fixes sont plus répandues que les flims. Enfin, malgré des développeurs qui semblent motivés, Google semble mettre moins d'ardeur à promouvoir WebP qu'il n'en avait mis pour WebM.

  • # Journal

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

    Note de l'auteur : j'ai publié cet article dans le journal plutôt que comme dépêche à la une, parce que ce format ne me semble pas encore finalisé.

    • [^] # Re: Journal

      Posté par . Évalué à  -10 .

      Journal ou dépêche, une bonne relecture avant publication, ça nous aurait évité les multiples fautes d'orthographe ou autres erreurs de saisie comme « WebP propose permet » ou « flims » et ainsi de faire un article totalement finalisé.

      • [^] # Re: Journal

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

        ou « flims »

        http://www.cyclim.se/

      • [^] # Re: Journal

        Posté par (page perso) . Évalué à  1 . Dernière modification : le 25/11/11 à 10:45

        la modération peut être faite a posteriori sur les journaux et, sinon, je rejoins Tanguy< sur les flims, je ne vois pas d'erreur, d'autant plus si cela ne concerne pas le cyclimse :-)

        édition : +ne + pas /o\

        • [^] # Re: Journal

          Posté par . Évalué à  5 .

          je rejoins Tanguy< sur les flims, je ne vois pas d'erreur, d'autant plus si cela concerne le cyclimse :-)

          Justement non, ce n'est pas sur le cyclimse.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Journal

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

            Merci de votre compréhension.

          • [^] # Re: Journal

            Posté par (page perso) . Évalué à  -6 .

            J'ai corrigé mon commentaire ;-) pas réveillé ce matin :p

            • [^] # Re: Journal

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

              Tant que la fonctionnalité n'est pas disponible pour tous, les modérateurs ne devraient pas user de leur pouvoir pour modifier ce qu'ils font en tant qu'utilisateur. Il est refusé aux utilisateurs de modifier leur commentaire si il font des fautes, donc pas de passe-droit, les fautes doivent rester!

              les modos doivent suivre les même règles que les simples "citoyens", halte à l'abus de pouvoir! ;-)

              • [^] # Re: Journal

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

                Tu peux aussi envoyer un mail sur la liste des modérateurs pour qu'ils éditent tes commentaires.

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

                • [^] # Re: Journal

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

                  Sur un site qui se veut critique envers le pouvoir étatique en place et ses passes-droits, un "citoyen" du site ne devrait pas avoir le droit de se faire justice lui-même (même quand il peut) et doit donc envoyer un mail aux modos, tout en se mettant en retrait, pour que les autres modos jugent la pertinence de la demande et agissent en fonction.

                  Dur d'être juste, de respecter les règles pour tous, et tout ce bla bla pour une simple édition de commentaire ;-).

                  • [^] # Re: Journal

                    Posté par . Évalué à  3 .

                    Sur un site qui se veut critique envers le pouvoir étatique en place et ses passes-droits

                    C'est écris où ?

                    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: Journal

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

                euh va falloir arrêter avec l'abus de pouvoir hein ;-) il me semble l'avoir fait dans les règles en indiquant en commentaire et dans le commentaire l'action prise.
                Mais, bien sûr, je pourrais aussi continuer à modifier silencieusement les journaux et les commentaires (principalement de la syntaxe Markdown sur les listes notamment, parfois quelques coquilles gênantes), pas de souci avec cela. Chercher à opposer admodérolecteur et participants au site est stérile àmha, nous sommes tous participants, au même niveau, parfois avec un peu plus de possibilités utilisées à bon escient de part et d'autre.

                les modos doivent suivre les même règles que les simples "citoyens"

                Je ne crois pas, non ; cf. http://linuxfr.org/regles_de_moderation qui s'appliquent en plus aux admodérolecteurs. Tu peux éventuellement commencer à en appliquer certaines en revanche, qui te sont accessibles, comme je le fais déjà ;-) (leur identification est laissée à titre d'exercice).

                En revanche, en tant qu'utilisateur, je te rejoins et c'est ce que je fais généralement s'il y a eu des commentaires (sauf quand il y aurait un trait d'humour ou une coquille éhontée par encore relevée). Cela correspond à ce qui ressort de la demande sur l'édition de textes (qui pourrait être encore précisée).

    • [^] # Re: Journal

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

      Je pense que ça aurait pu faire une bonne dépêche pour faire un état des lieux vu qu'il ne me semble pas que le format sera finaliser rapidement.

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

    • [^] # Re: Journal

      Posté par . Évalué à  3 .

      je pense que ça valait la dépêche.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # spéciale dédicace

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

    Ah oui c'est pratique, ça, l'InternetP.

  • # Webp semble incomplet...

    Posté par (page perso) . Évalué à  10 . Dernière modification : le 25/11/11 à 00:23

    Visiblement, Mozilla a rejeté WebP. Une explication un peu plus détaillé est disponible dans une entrée du blog de Jeff Muizelaar datant d'avril 2011. Il y est notamment dit :

    WebP also comes across as half-baked. Currently, it only supports a subset of the features that JPEG has. It lacks support for any color representation other than 4:2:0 YCrCb. JPEG supports 4:4:4 as well as other color representations like CMYK. WebP also seems to lack support for EXIF data and ICC color profiles, both of which have be come quite important for photography. Further, it has yet to include any features missing from JPEG like alpha channel support. These features can still be added, but the longer they remain unspecified, the more difficult it will be to adopt.

    Ce que j'en retiens, notamment c'est qu'il n'y a pas de métadonnées dans le format WebP et que la représentation de couleurs CMYK (CMJN en français) n'est pas supportée non plus. Un des gros intérêts de JPEG est d'être utilisable indifféremment pour le web, pour l'impression, et pour le stockage de métadonnées associées au contenu image.

    Trois exemples rapides :

    • les agences de photo type AFP utilisent massivement les méta-données JPEG ; par ailleurs elles distribuent principalement leurs images via leur plateforme web.
    • les profils de couleur CMJN sont inévitables dans le domaine de l'édition et de l'impression.
    • les métadonnées des fichiers image sont visiblement supportées par certaines galleries de photo en ligne telles que Piwigo.

    Google a une vision 100% web du monde, ce qui est bien, mais pas top.

    • [^] # Re: Webp semble incomplet...

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

      Google a une vision 100% web du monde, ce qui est bien, mais pas top.

      Alors que Mozilla refuse de gérer dans leur navigateur web un format d'image parce que dans l'absolu pour communiquer entre deux suites de photographies professionnelles il peut poser problème.

      Faut dire que virer le numéro de version et gérer websocket, c'est vachement plus crucial que gérer les clés SSL > 8k ou gérer les nouveautés du pur web.

      • [^] # Re: Webp semble incomplet...

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

        J'ai pas dit que la fondation Mozilla gérait les priorités "comme il faut". Ce que je dis, c'est que Google dit que son format WebP est mieux que JPEG, que Mozilla trouve néanmoins qu'il n'est pas mieux et que j'adhère à cette vision "WebP n'est pas mieux que JPEG".

        En ce qui concerne la gestion de ce qui est crucial par la fondation Mozilla, je pense que le troll devrait prendre dans la journée :)

    • [^] # Re: Webp semble incomplet...

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

      Ce que j'en retiens, notamment c'est qu'il n'y a pas de métadonnées dans le format WebP

      Ça vient de changer, justement, outre l'alpha et les profils ICC, WebP peut maintenant intégrer des méta-données XMP. Bref, on dirait bien que Google réagit aux critiques de ce format et le corrige selon les besoins qui apparaissent.

    • [^] # Re: Webp semble incomplet...

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

      Mozilla rejette depuis longtemps le support de MNG qui possède pourtant toutes les qualités requises...

      Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

      • [^] # Re: Webp semble incomplet...

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

        Geocities et les gifs animés c'était mieux à vent !

      • [^] # Re: Webp semble incomplet...

        Posté par . Évalué à  9 .

        Mozilla fait le grand écart entre le navigateur préféré des geeks et un bac à sable pour madame Michu, et ça commence à se ressentir.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Webp semble incomplet...

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

        Mozilla rejette depuis longtemps le support de MNG qui possède pourtant toutes les qualités requises...

        Mozilla a abandonné MNG pour supporter APNG, qu'Opera supporte aussi. Chez Konqueror, c'est l'inverse : MNG est supporté mais pas APNG. La plupart des autres navigateurs ne supportent ni l'un ni l'autre.

        Après lequel d'entre APNG et MNG est le meilleur format, je n'en sais rien.

        • [^] # Re: Webp semble incomplet...

          Posté par . Évalué à  2 .

          Si je me souviens bien, l'abandon du MNG n'a rien à voir avec le support d'APNG. MNG a été abandonné à l'époque parce que le code en ajoutant le support était considéré comme "trop important", pour un firefox qui avait des ambitions de légèreté. Il doit y avoir des traces de cette histoire dans le suivi de ce bug : https://bugzilla.mozilla.org/show_bug.cgi?id=18574

          APNG est venu plus tard.

          • [^] # Re: Webp semble incomplet...

            Posté par . Évalué à  2 .

            Une image MNG ne peut pas être lue par un navigateur supportant les images PNG. Du coup, il n'y a pas de possibilité d'adoption progressive de ce format sur le web. Ce défaut ajouté a la taille du code requise pour gérer le MNG (commentaire ci-dessus) a poussé Mozilla a inventer l'APNG qui n'a pas rencontré beaucoup plus de succès.

        • [^] # Re: Webp semble incomplet...

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

          Heu le mieux c'est pas genre le standard ?

          Parce que le truc batard de Mozilla que personne n'utilise et qui a été retoqué comme standard parce que considéré comme boiteux... C'est un peu mort.

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Webp semble incomplet...

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

      "Google a une vision 100% web du monde, ce qui est bien, mais pas top."
      À mon avis, google a très envie d'avoir les méta-données dans webP, c'est un très bon moyen pour savoir où a été prise une photo par exemple…

      • [^] # Re: Webp semble incomplet...

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

        Du calme : cette discussion est caduque, WebM prenant déjà en charge des méta-données.

        • [^] # Re: Webp semble incomplet...

          Posté par . Évalué à  1 .

          rahhhh décidément ça avance trop vite!!! Mauvais jour pour les trolls ;)

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Webp semble incomplet...

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

          J'ai pas vu EXIF par contre hélas, qui est pourtant déjà très largement répandu.

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

          • [^] # Re: Webp semble incomplet...

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

            XMP étantextensible, je ne serais pas surpris qu'il soit possible de représenter EXIF en XMP.

            • [^] # Re: Webp semble incomplet...

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

              Oh l'usine à gaz...

              • [^] # Re: Webp semble incomplet...

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

                Pas d'accord. Il y a un vieux format, limité : EXIF. Il y a un truc plus récent, extensible : XMP. A priori, Adobe, qui ont créé XMP parce qu'ils trouvaient EXIF trop limité, ont dû penser à faire en sorte que XMP permette de représenter au moins tout ce que fait EXIF. Par conséquent, on doit pouvoir passer de EXIF à XMP sans perte.

                À partir de là, Google, qui ont conçu un nouveau format d'image, ont simplement pris ce qui se faisait de mieux pour les méta-données : XMP. C'est plus propre que de le prendre EXIF et XMP alors que le second fait tout ce que fait le premier, non ?

                • [^] # Re: Webp semble incomplet...

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

                  Ok, je n'avais pas compris, je croyais que tu voulais mettre le binaire EXIF dans un champ XMP.

                  Maintenant, ce n'est pas créé de manière "globale", c'est fait par une seule boite (Adobe), mais si ça peut aider par rapport à EXIF (qui pour mémoire est une grosse merde à coup d'extension proprio non documentées), oui c'est tant mieux.

                  • [^] # Re: Webp semble incomplet...

                    Posté par . Évalué à  3 .

                    je croyais que tu voulais mettre le binaire EXIF dans un champ XMP.

                    Wow, j'ai souvent des idées tordues mais là, je suis impressionné :-)

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Webp semble incomplet...

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

                      Tu ne peux pas imaginer sur quoi je peux tomber comme merdes dans les conteneurs.
                      Rien qu'hier, j'ai trouvé un bon compétiteur pour le concours du truc le plus débile : du JPEG (avec des données EXIF) transcodé en Base64 et mis dans une balise XML elle-même mise dans un champs binaire "privé" d'un conteneur. Si, si, il y a des gens capables de faire ça... Alors, du EXIF dans un champ XMP, ben c'est possible qu'une personne y pense!

      • [^] # Re: Webp semble incomplet...

        Posté par . Évalué à  1 .

        Parce qu'ils compte le mettre dans les APN ?

        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: Webp semble incomplet...

          Posté par . Évalué à  7 .

          Indice : Android → Smartphone → Appareil photo

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Webp semble incomplet...

            Posté par . Évalué à  1 .

            A oui excuse-moi, je parlais d'appareils photo pas de webcam.

            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: Webp semble incomplet...

              Posté par . Évalué à  2 .

              Bah en même temps, la plupart des smartphones ont les deux.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Webp semble incomplet...

      Posté par . Évalué à  6 .

      Google a une vision 100% web du monde, ce qui est bien, mais pas top.

      Et alors ? Je n'ai pas l'impression que Google cherche à remplacer JPEG dans ses cas d'usage. Ils cherchent juste à ce que les images faites pour le web uniquement (et il y en a une quantité astronomique entre les avatars, les banderoles et les thèmes des sites) aient une alternatives optimisées pour le web.

      PNG n'est pas bien foutu pour les photos, c'est pas pour ça qu'il et mauvais et pas utilisé.

      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.

  • # Gimp supporte également WebP...

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

    à l'aide de ce plugin d'import/export. Ceci ne m'étonne pas d'ailleurs : je me souviens qu'à l'époque où j'avais encore un lecteur de disquette sur mon pentium 166MMX, Gimp était le seul logiciel capable d'importer mes illustrations d'enfant, créées à la souris sur mon Atari avec Degas Elite. Snif :.)

    D'ailleurs, une rapide recherche google donne en troisième réponse le code source du plugin en question... :-o

  • # Cool encore un format !

    Posté par . Évalué à  10 .

    Bah JPEG fournit du lossless, en tant qu'extension au JPEG de base, ou dans la mouture JPEG2k.

    J'avoue que je ne comprend pas trop pourquoi webpeg « peut éviter aux béotiens de s'interroger — et de se tromper — sur le format approprié », à un moment donné l'utilisateur devra choisir entre lossless ou pas lossless. Si l'application le fait pour lui, elle aurait aussi bien pu choisir PNG ou JPEG. Je pense que l'utilisateur lambda n'a même jamais remarqué qu'il y avait une différence entre les formats d'images existant. Son appareil photo enregistre en JPEG, son Inkscape exporte en PNG, les extensions sont cachés sous Windows, etc.

    • [^] # Re: Cool encore un format !

      Posté par . Évalué à  6 .

      Bah JPEG fournit du lossless, en tant qu'extension au JPEG de base, ou dans la mouture JPEG2k.

      Les taux de compressions sont-ils comparables à ceux de WebP ? Parce que c'est quand même le point le plus mis en avant.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Cool encore un format !

        Posté par . Évalué à  7 .

        Le lossless JPEG, la version 16 bits ne sont utilisable nul part.

        Le JPEG2k est tellement plein de brevets qu'il n'est pas prêt d'aller sur le web. Il ne sert que pour la cinéma numérique.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

      • [^] # Re: Cool encore un format !

        Posté par . Évalué à  -2 .

        Hehe.
        A l'epoque des trolls theora/h264, on entendait souvent dire "bah, 30% ca fait pas une enorme difference".

        /me sifflote

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: Cool encore un format !

          Posté par . Évalué à  3 .

          Ce qui est dommage dans l'ouverture de VP8, c'est qu'elle a eclipsé le travail sur Theora : les améliorations entre la 1.0 et 1.1 était assez impressionnantes pour espérer quelque chose de potable pour les versions suivantes.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Format d'image ultime

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

    L'une des propriétés que j'attends d'un « format d'image ultime » serait la suivante : la possibilité d'enregistrer des images compressées relativement efficacement avec perte mais en conservant un peu plus d'informations colorimétrique que ne peut en percevoir l'œil humain.

    Formulé ainsi, cela paraît quelque peu ridicule, mais nombre d'appareils photographiques produisent régulièrement des images avec des expositions modérément justes. Pour pouvoir y palier, il est nécessaire d'enregistrer des matrices brutes compressées sans aucune perte et contenant bien plus d'informations que nécessaire. Avec un format type jpeg mais autorisant un petit « eV » de plus dans les claires comme dans les obscures et 2 eV dans les tons médians, la plupart des images pas trop à l'ouest pourraient être sauvées. Et le tout au prix d'une augmentation de seulement 50% environ de la taille des fichiers au lieu des fois 3 à 6 des images « raw ».

    Donc mes questions : est-ce que ce genre de chose existe ? Est-ce disponible dans webP ? Est-ce prévu dans webP ?

    Si ce n'est pas le cas et comme noël approche : « Cher monsieur google ; j'ai été bien sage cette année, je me suis peu acharné à pourrir la vie de mes collègues, j'ai souvent évité de lancer des trolls sur linuxfr. Alors puisque tu me lis, s'il te plaît introduit cette fonctionnalité dans ton format d'image, puis fais le adopté par les fabricant d'appareils photographiques. Merci. »

    • [^] # Re: Format d'image ultime

      Posté par . Évalué à  -10 .

      Pour les appareils photos, ça existe et ça s'appelle le RAW.

      Pour une image diffusée sur le web, cela n'a aucun intérêt je pense, ce serait même contre-productif dans la mesure ou toute informatiion additionelle doit être codée et induira donc inévitablement une pénalité en terme de poids de l'image compressée. Et si tu dis que tu penses conserver 8 bits par couleur, alors c'est contre-productif parce que tu vas perdre de la précision dans les couleurs visibles...

      • [^] # Re: Format d'image ultime

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

        Pour les appareils photos, ça existe et ça s'appelle le RAW.

        Je cite le commentaire auquel tu réponds

        Et le tout au prix d'une augmentation de seulement 50% environ de la taille des fichiers au lieu des fois 3 à 6 des images « raw ».

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

        • [^] # Re: Format d'image ultime

          Posté par . Évalué à  2 .

          En fait, cela devrait être possible simplement si le webp supporte des images sur plus de 8 bits par canal. Les capteurs récents en sont à 14 bits.

          D'ailleurs, il pourrait faire un mode de compression avec perte en utilisant des couleurs absolus et non seulement un raw ou un mapping sur RGBa. En gros, l'image d'un capteur est transformé en image ayant des canaux 8 bits en tenant compte de la couleur de la lumière ambiante, donc les couleurs stockées sont les couleurs apparentes que verrait un œil humain. Si on stock les 14 bis, plus la couleur de la lumière ambiante, on stocke une information de couleur absolue qu'il faut ensuite traduire selon la lumière ambiante de la prise de photo (car l'oeil fait une balance des blancs) et les caractéristique du support. C'est un sorte de raw mais avec compression avec perte.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: Format d'image ultime

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

            Si tu cherches un format d'images spécialisé dans la représentation de photographies avant traitement, pas de chance, WebM n'a absolument pas cette vocation. C'est vrai que ce ne serait pas un luxe de disposer d'un format standard pour cela, mais WebM n'est simplement pas fait pour ça : c'est un format de représentation d'images finalisées.

            • [^] # Re: Format d'image ultime

              Posté par . Évalué à  2 .

              Pourquoi cela ne pourrait pas être le même ?

              Il suffit d'utiliser un espace de colorimétrie absolue avant compression avec perte.

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: Format d'image ultime

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

                Parce que le décodeur hardware aura besoin de beaucoup plus de puissance?

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

                • [^] # Re: Format d'image ultime

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

                  Pardon? Une fonctionnalité en plus, ça ne demande pas de hardware plus puissant quand on ne l'utilise pas. Le reproche est de ne pas permettre, ça ne dit pas qu'il faut obliger.

            • [^] # Re: Format d'image ultime

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

              Certes mais une grande qualité pour un format est d'être polyvalent. C'est une sorte de qualité récursive : le jpeg était très polyvalent ; il est devenu très répandu, ça polyvalence s'en est trouvée accrue ; il n'en est que plus indispensable.

              À mon goût le seul défaut sensible du jpeg c'est de ne permettre que des latitudes de retouches restreintes. Pourtant nombreux sont ceux qui, nonobstant cette carence, l'utilisent tout de même pour leurs travaux photo pré-publication. Ainsi, il me semble très classique de prendre des photo en les enregistrant en jpeg, les travailler, puis éventuellement les publier sur le web. Le jpeg servant là de bout en bout avec différentes options pour l'adapter à l'usage.

              Il me semble que permettre une amélioration sensible dans une méthode de travail aussi courante que celle décrite ci-avant serait pour webP un argument de poids favorisant son adoption. Alors que webP promet/permet déjà un florilège de ce qui se fait de mieux en matière de gestion des dessins comme des photographies, y aurait-il quelque raison technique qui préviendrait l'addition d'un mécanisme qui le rendrait indispensable pour tous les photographes amateurs ? Je veux dire, outre le fait que de toute évidence google n'a d'intérêt directe que pour le résultat final disponible sur le net.

              • [^] # Re: Format d'image ultime

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

                le jpeg était très polyvalent

                ???

                Définis « polyvalent » pour voir ?

                À mon goût le seul défaut sensible du jpeg c'est de ne permettre que des latitudes de retouches restreintes

                ???

                Définis « latitude de retouche »…

                Il me semble que permettre une amélioration sensible dans une méthode de travail aussi courante que celle décrite ci-avant serait pour webP un argument de poids favorisant son adoption. Alors que webP promet/permet déjà un florilège de ce qui se fait de mieux en matière de gestion des dessins comme des photographies, y aurait-il quelque raison technique qui préviendrait l'addition d'un mécanisme qui le rendrait indispensable pour tous les photographes amateurs ? Je veux dire, outre le fait que de toute évidence google n'a d'intérêt directe que pour le résultat final disponible sur le net.

                Euuuuh… C'est du français ça ?

                • [^] # Re: Format d'image ultime

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

                  Polyvalent : peu s'utiliser pour décrire une entité ayant potentiellement plusieurs emplois sensiblement différents. D'après ATILF : « […] qui touche plusieurs domaines […] Qui peut être utilisé à différents usages, de différentes manières […] Qui possède plusieurs aptitudes ou capacités, qui peut remplir plusieurs fonctions […] »

                  Précisément le sens que je donnais à ce mot. Personnellement j'utilise des jpeg pour faire de la photographie, de la retouche d'image, du stockage d'images, de la publication d'images sur le web, etc… Il me semble donc que polyvalent fait un excellent attribut aux côtés de jpeg.

                  Latitude de retouches : OK, là j'utilise cette expression pour décrire quelque chose de très particulier que je n'ai pas forcément explicité suffisamment. Selon moi, l'une des principales limites de la retouche d'images enregistrées en jpeg vient de ce que modifier les courbes de couleurs provoque immédiatement une dégradation sensible de la qualité de l'image. le phénomène peut être quantifié empiriquement en observant la formation de trous dans les histogrammes indiquant les densités absolues de pixels de chaque niveau. Selon moi disposer d'une « bonne latitude de retouche » consisterait en ce que la formation des dits trous ne se traduise pas (pour des modifications minimes) par des effets perceptibles par l'œil humain sur l'image. Avec le jpeg c'est le cas car le nombre de bit par canal est extrêmement optimisé afin de réduire la taille de fichiers.

                  « Euuuuh… C'est du français ça ? »

                  Je n'ai quasiment jamais eu la moyenne dans cette matière là. Ça se lit tant que ça ?

                  • [^] # Re: Format d'image ultime

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

                    Polyvalent : […]
                    Précisément le sens que je donnais à ce mot. Personnellement j'utilise des jpeg pour faire de la photographie, de la retouche d'image, du stockage d'images, de la publication d'images sur le web, etc…

                    À ce compte-là, n'importe quel format de compression avec pertes ferait l'affaire. C'est une caractéristique générale de ces formats que tu décris là : ils sont adaptés pour stocker des photographies, quel qu'en soit l'usage tant qu'il n'est pas trop spécialisé.

                    Je ne considère pas cela comme polyvalent. Par exemple, JPEG est totalement inadapté aux dessins.

                    Latitude de retouches

                    Ce que tu donnes comme définition, c'est : compresse, mais avec des pertes pas trop gênantes. C'est le cas de n'importe quel format efficace utilisé sans excès. Pour cela, WebM fera mieux que JPEG.

                    • [^] # Re: Format d'image ultime

                      Posté par . Évalué à  1 .

                      Ce que tu donnes comme définition, c'est : compresse, mais avec des pertes pas trop gênantes. C'est le cas de n'importe quel format efficace utilisé sans excès. Pour cela, WebM fera mieux que JPEG.

                      Pour faire des corrections minimes sur l’exposition, il faut avoir des bits supplémentaire par pixels, ie. ne pas avoir seulement 256 niveaux par canal, mais 512 par exemple (c’est aussi un reproche qui est souvent fait à Gimp — du nouveau de ce côté là ?). Le problème est que 256 niveaux par canal semble un peu limite, il suffit d’une retouche mineure pour se rendre compte qu’il manque de l’information. Il ne s’agit pas de compression, mais de savoir combien de bits par canal peut avoir WebM.

                      • [^] # Re: Format d'image ultime

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

                        ie. ne pas avoir seulement 256 niveaux par canal, mais 512 par exemple (c’est aussi un reproche qui est souvent fait à Gimp — du nouveau de ce côté là ?)

                        Rassurez-moi : GIMP gère les formats 9, 10, 11, 12, ou 16 bits quand même? Je sais pas moi, on dit qu'il est au niveau de Photoshop et que si Photoshop est préféré c'est pas pour des questions techniques, donc je m'attends à ce que le 16 bits (et CYMK) soient gérés. (bon, moi pas amateur de retouche, je n'ai pas fait attention à ça, mais la on parle de gens un peu intéressés par la photo)

                        • [^] # Re: Format d'image ultime

                          Posté par . Évalué à  4 .

                          Je viens de regarder, 32 bits par canal depuis 2009, grâce à GEGL.

                        • [^] # Re: Format d'image ultime

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

                          De toutes façons, quel que soit le nombre de bits par canal (bpc) géré par gimp ou d'autres logiciels, tant qu'ils ne sont nourris qu'au jpeg 8 bpc, cela ne fait quasiment aucune différence (réelle flottante). D'où d'ailleurs l'éventuel intérêt pour des formats compressés avec pertes mais un peu plus riches en bpc.

                    • [^] # Re: Format d'image ultime

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

                      « Ce que tu donnes comme définition, c'est : compresse, mais avec des pertes pas trop gênantes. C'est le cas de n'importe quel format efficace utilisé sans excès. Pour cela, WebM fera mieux que JPEG. »

                      Absolument pas ; toujours mes lacunes en expression écrite…

            • [^] # Re: Format d'image ultime

              Posté par . Évalué à  2 .

              En fait, vu la complexité de l'affichage, il n'y a pas vraiment le choix pour avoir de la qualité. La norme HDMI supporte déjà 10 ou 12 bits par canal. Les écrans LED par rapport au CFL peuvent avoir des gamuts différents (si le gamut est trop grand, il peut y avoir des paliers visibles si on reste en 8 bits). Je ne parle pas de la galère pour faire une retouche à l'écran et espérer avoir les mêmes couleurs après un tirage de photo.

              Le seul moyen d'y arriver (simplement, sans sonde à 150€) est d'avoir un format de stockage en colorimétrie absolue (CIE xyY) avec des références de couleur local pour traduire les couleurs en valeur pour l'écran ou une imprimante ( https://en.wikipedia.org/wiki/CIECAM02 ).

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: Format d'image ultime

      Posté par . Évalué à  3 .

      Sinon, tant qu'à faire, autant essayer de gérer ce genre de données (pour lesquelles il n'existe pas encore de format standard) : https://www.lytro.com/

  • # Animation

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

    Si j'ai bien compris ils ont pris un format vidéo, en ont extrait un format d'image puis ils ont fait un format d'animation. Il n'y a pas une boucle là ?

    La différence qui me vient entre une vidéo et un gif animé est que ce dernier permet de faire une animation sur fond transparent. Mais est-ce que le format de vidéo et d'animation n'auraient pas intérêt à être fusionnés ?

    • [^] # Re: Animation

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

      La différence qui me vient entre une vidéo et un gif animé est que ce dernier permet de faire une animation sur fond transparent.

      Non, pas seulement. Les animation ne sont pas faites pour faire des flims, mais bien des animations, typiquement des schémas… animés. En particulier, cela implique de pouvoir afficher les images pendant des temps arbitrairement longs.

      • [^] # Re: Animation

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

        En particulier, cela implique de pouvoir afficher les images pendant des temps arbitrairement longs.

        Et oh miracle, les formats vidéos (par exemple... mp4, mais matroska aussi, donc j'imagine que WebM aussi) permettent ça (durée arbitraire de chaque image, il y a un "timestamp").

        Alors reprenons :
        - On a WebM pour faire des vidéos/animations/appelle ça comme tu veux, tant que c'est une suite d'images
        - On sort le format de compression de WebM pour du WebP, "plus simple" pour une image (alors que WebM permet aussi une seule image, ben oui, une image fixe, c'est une vidéo avec une seule image)
        - Mais en fait, on veut de la vidéo/animation/appelle ça comme tu veux, donc on étend WebP pour faire de la vidéo, mais pas façon WebM, ça ne serait pas marrant, inventons une nouvelle méthode.

        Donc bon, la, on a juste un format de conteneur en plus pour la vidéo (animations/appelle ça comme tu veux comprise). On s'amuse bien en ce moment chez Google?
        (pour le GIF, ça se comprenait, on n'avait pas encore la balise vidéo, donc un bon gros hack pourri mais qui marche, mais de nos jour, la balise vidéo existe...)

        • [^] # Re: Animation

          Posté par . Évalué à  7 .

          Et attention, on pourra bientôt ajouter des sons au format d'images animées.

          C'est une révolution, il faut tout upgrader!

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Animation

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

          Si le WebP a du succès, ce serait un grand progrès pour les jeux 2D: il n'existe à l'heure actuelle aucun format standard pour les sprites animés.

          Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

          • [^] # Re: Animation

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

            Un grand progrès, c'est un bien grand mot :)

            Par exemple je n'ai pas l'impression que le GIF ait percé dans les jeux aux animations simples, on retrouve souvent la vielle technique du « je mets plein de sprites dans une image et je fais un fichier indiquant la durée d'affichage de chaque sprite ». Alors pour des animations un peu compliquées, genre n lectures entre deux frames, avec allers-retours ou toujours en avant, ou la possibilité de changer dynamiquement la vitesse de lecture, ou encore avec la rotation de certaines frames ; je ne pense pas qu'un autre format d'animation « générique » puisse devenir un standard.

            • [^] # Re: Animation

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

              Faute de mieux j'utilise du GIF dans Newton Adventure. C'est plus pratique que d'inventer un format propriétaire, mais la limite de 256 couleurs est vraiment un handicap.

              Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

              • [^] # Re: Animation

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

                En plus il n'y a pas de canal aplha, donc tes sprites vont être tout aliasés. La technique classique consiste à mettre les différentes frames les une à côté des autres dans une image png, et le timing soit dans ton code s'il est toujours identique pour tes différentes animations, ou dans un autre fichier de resource pour faire plus propre. C'est fait comme ça pour les particules animées des décors de Hedgewars par exemple.

                En 2002, j'ai fait un stage dans une boite de jeux vidéos (GameBoy et GBA principalement) et tous les sprites d'un niveau (donc N sprites pour une animation) étaient agencés dans une même grosse image PNG (c'est un outil interne qui pondait ladite png) ; c'est une technique ultra classique sur ces petites plateforme, et c'est peut être même une exigence (les sprites sont gérés en hardware et une partie de la mémoire leur est donc consacrée).

                • [^] # Re: Animation

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

                  C'est peut être ultra classique et ultra optimisé sur de vieilles machines, mais en 2011 sur mon gros PC, c'est LOURD.

                  Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                  • [^] # Re: Animation

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

                    Qu'est ce qui est lourd ?

                    Autant la technique de la grosse image avec toutes les resources d'un niveau est chiante à faire : il faut agencer les différentes frames de tailles différentes en gachant le moins de place possible. Mais cette technique est très dispensable et ce n'est pas celle que je te conseillais.

                    En revanche faire un sprite animé en 32x32 avec 4 frames avec une image de 128x32 (ou 32x128 peu importe) par exemple, c'est franchement pipeau, tant au niveau du code qu'au niveau du graphisme.

                    Au niveau des formats 3D c'est bien plus le bordel et la tout le monde fait un peu à sa sauce.

                    • [^] # Re: Animation

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

                      Ce qui est lourd, c'est d'avoir un format spécifique et un code d'affichage spécifique pour chaque jeu, de ne pas avoir d'outils d'édition d'animation commun et de se taper des scripts de conversion ou d'éditer les animations à la main.

                      Les créateurs de jeux libres utilisent beaucoup les sites comme http://opengameart.org pour échanger des animations. Sauf que faute de format standard, on se retrouve avec des grilles ou des suites d'images sans donnée sur l'animation...

                      Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                      • [^] # Re: Animation

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

                        Ok avec l'explication je comprends un mieux ta frustration. Ton commentaire m’inspire plusieurs réflexions :

                        • Je n'ai évidemment jamais dit que "ma" technique était la panacée. Ce n'est qu'un hack, mais parfois je pense qu'il faut être pragmatique et accepter de faire un hack en 3 minutes mais qui marche plutôt bien, même si le perfectionniste qui est en nous en prend un coup !

                        • Le format MNG me semblait pas trop mal (je ne le connais pas bien cependant), mais on ne peut pas dire qu'il soit très connu ou populaire.

                        • Avoir un outil d'animation commun serait évidemment très bien. Après, la création d'un jeu restera beaucoup de boulot et ce n'est que la partie émergée de l'iceberg. Un outil de création entièrement intégré (comme pour Flash) serait encore bien mieux ; et même la il y aurait toujours de quoi faire mieux etc... Tout ça pour dire que que n'est qu'un minuscule problème à mon avis (ce qui ne veut pas dire que ça ne vaut pas la peine de se pencher dessus hein).

                        • Malgré tout le respect que je peux avoir pour OpenGameArt, je crois malheureusement que pour les graphismes ce genre d'initiative n'est pas très efficace (mais j'espère me tromper) . Pour les sons ça marche bien, car primo depuis qu'on sait faire du son qualité CD on n'a plus vraiment de gros progrès technique à faire, deuxio même si avoir un set sonore spécifique est préférable, avec un set "réaliste" et un set "cartoon" génériques doit sûrement couvrir beaucoup de besoins. Mais pour les graphismes, la réutilisabilité est vraiment faible au final : si je cherche des modèles 3D très détaillés pour de l'heroic fantasy, des modèles 3D lowpoly de SF ou des sprites en 3D isométriques d'heroic fantasy ne me sont pas utiles du tout. Je ne connais pas de jeu libre vraiment abouti utilisant OpenGameArt.

                        • Une idée à la con : quelqu'un qui poste une image animée sur OpenGameArt, et qui a donc conscience du manque d'information de timing, pourrait toujours l'indiquer dans le nom du fichier, genre hero__100ms.png (il faut que le timing soit toujours le même entre les frames, mais c'est bien souvent le cas).

                        Désolé si je t'ennuie, je peux être loquace sur des sujets qui me passionnent. Bonne journée :)

                        • [^] # Re: Animation

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

                          Je ne connais pas de jeu libre vraiment abouti utilisant OpenGameArt

                          Je ne sais pas pour la 3D, mais en 2D, si tu regardes bien, beaucoup de jeux libres reprennent des images issues d'OpenGameArt.

                          un outil de création entièrement intégré (comme pour Flash) serait encore bien mieux

                          On est loin de l'animation de sprite là :-) Mais sinon il ya SVG pour ça. Il existe aussi des outils de création de jeux complets comme Game Editor.

                          Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                          • [^] # Re: Animation

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

                            Je ne sais pas pour la 3D, mais en 2D, si tu regardes bien, beaucoup de jeux libres reprennent des images issues d'OpenGameArt.

                            Y a-t-il dans le lots des jeux "aboutis" ? J'entends par là des jeux auxquels par exemple des gens se foutant du libre et qui s'y connaissent un minimum en jeux joueraient (pour peu qu'on leur montre). Ce n'est pas tant que l'avis des non libristes m'intéresse spécialement, mais ça permet d'avoir un avis purement technique ; tous ceux qui utilisent Firefox ne sont pas des libristes, et c'est parce que Firefox est tout simplement bon. Je dis ça sans méchanceté aucune ; j'ai moi même commencé un jeuavec un pote depuis des années, et je sais bien que personne ne s'y amusera avant longtemps (mis à a part nous à le faire !), parce que c'est long et difficile de garder la motivation. Je pense à des jeux de la qualité de Wesnoth ou Hedgewars par exemple.

                            On est loin de l'animation de sprite là :-) Mais sinon il ya SVG pour ça

                            Si tu as regardé mon lien tu as pu voir que j'adore le SVG (il n'y a pas beaucoup de tarés qui font leurs textures en SVG !); je travaille souvent en vectoriel même si le travail final doit être du bitmap (je dois être le seul à fournir ses sources SVG pour ses contributions à Hedgewars malheureusement). Je ne suis pas sûr qu'on puisse faire tout un jeu (un "vrai") rien qu'avec du SVG ; mais dans la pratique si je pouvais avoir les animations dans Inkscape ça serait déjà bien, parce que je les attends depuis longtemps !

                            Il existe aussi des outils de création de jeux complets comme Game Editor.

                            Je ne connaissais pas ça a l'air sympa merci.

    • [^] # Re: Animation

      Posté par . Évalué à  1 .

      Pour moi, la différence entre une image animée et une vidéo est l'utilisation dans cette dernière d'images de référence (I ou P, je ne me souvient plus de la terminologie), le suivantes n'étant constituées que de "delta" par rapport à la référence.
      Pour le GIF (et je suppose pour le WebP), toutes les images sont "entières".

      • [^] # Re: Animation

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

        Pour moi, la différence entre une image animée et une vidéo est l'utilisation dans cette dernière d'images de référence (I ou P, je ne me souvient plus de la terminologie),

        Donc tous les films au ciné sont des images animées, avec ta définition (ben oui, c'est du JPEG-2000 dans du MXF, que des I-Frames = Intra only, impossible de faire des P-Frames).

        H264, c'est quoi pour toi? pour faire de la vidéo (il peut faire des P-Frames) ou une image animée (il peut faire que des I-Frames)?

        Faut arrêter le délire et le mélange de choses qui n'ont rien à voir : la dénomination ne change pas en fonction des capacités techniques d'un format. Surtout que qui peut le plus, peut le moins. On peut faire des différences subjectives, mais au niveau informatique, dès que ça bouge, c'est une vidéo/image animée/tout terme que vous voulez, car techniquement, c'est la même chose.

        • [^] # Re: Animation

          Posté par . Évalué à  2 .

          Hola, du calme. Je signalais simplement que le WebP animé n'était sans doute pas du WebM, puisqu'il n'utilise que des I-frames (au passage, merci pour la clarification).

          Après, évidemment qu'une image animée et une vidéo c'est fondamentalement la même chose. C'est juste qu'on a pris l'habitude, pour les fichiers stockés sur nos ordinateurs, de parler d'image animée pour les gif, et de video pour tout le reste encodé en h264/mpeg2/mpeg4/etc..., qui utilisent le plus souvent des P-frames.

          • [^] # Re: Animation

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

            Je signalais simplement que le WebP animé n'était sans doute pas du WebM, puisqu'il n'utilise que des I-frames

            Changer de nom/format/truc juste pour une option à l'encodage, c'est bourrin. Ben oui, c'est juste une option, comme la largeur, la hauteur, et j'en passe. Pas besoin de tout réinventer. Chez d'autres, on change juste un octet pour préciser le profile, comme ça les décodeurs non P-Frames disent "non". Juste un octet. C'est plus facile que le support d'un nouveau format.

            (au passage, merci pour la clarification).

            De rien.

            et de video pour tout le reste encodé en h264/mpeg2/mpeg4/etc..., qui utilisent le plus souvent des P-frames.

            Ca dépend vraiment du domaine. J'ai une tonne de fichiers mpeg2 ou h264 en stock sans aucune P-Frame. Et comme dit avant, le cinéma, l' "Intra only" est la règle.

            • [^] # Re: Animation

              Posté par . Évalué à  2 .

              qui peut le plus, peut le moins

              Tu prends le problème par le mauvais bout.

              J’ai un codec JPEG, je peux trivialement faire un codec MJPEG. Faire un codec MPEG complet (alors que le format intra de MPEG c’est du JPEG), c’est une autre paire de manche.

              Là le but c’est pareil : à partir d’un codec WebP, pouvoir faire trivialement un codec WebP animé sans avoir à coder un codec WebM complet.

              Bref, le but c’est de pouvoir en faire le moins sans être obligé de passer par la phase « en faire le plus ».

        • [^] # Re: Animation

          Posté par . Évalué à  3 .

          On peut faire une différence côté utilisateur: la vidéo, on peut la mettre sur pause, et la parcourir librement.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Animation

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

            Alors, je dirais qu'en fait, techniquement, vidéo et animation c'est effectivement le même concept. En revanche, les usages sont différents, aussi différents qu'entre aller au cinéma et assister à une conférence avec projection d'un support par transparents.

            Bref, ce n'est pas le même but, pas les mêmes usage, et par conséquent :

            1. il est intéressant de disposer de formats appropriés : typiquement, la compression sans pertes, l'alpha et la chronologie arbitraire sont beaucoup plus intéressants pour des animations que pour des vidéos ;
            2. les interfaces permettant d'interagir avec des vidéos et avec des animations sont différentes : typiquement, dans une animation on peut vouloir passer à l'image suivante, ce qui n'a pas un grand intérêt pour une vidéo.
            • [^] # Re: Animation

              Posté par (page perso) . Évalué à  4 . Dernière modification : le 25/11/11 à 13:41

              il est intéressant de disposer de formats appropriés : typiquement, la compression sans pertes, l'alpha et la chronologie arbitraire sont beaucoup plus intéressants pour des animations que pour des vidéos ;

              Ça ne change pas qu'on peut avoir le même format, avec quelques bits de différence, plutôt que tout réinventer, différemment.
              Par exemple, tout le monde décrie h264 car c'est le méchant bourré de brevet, mais... Il ne change pas de format juste pour un nouveau besoin, il étend le format, optionnellement. Quand ce sera compris, on aura fait un grand pas. Ici, point besoin de créer un nouveau système incompatible, WebM répond déjà au besoin (paraît que c'est le même format de compression non ? Donc, tu fais évoluer l'image dans WebM aussi... Tout le monde y gagne). Ça fait juste du boulot en plus pour le dév'.

              les interfaces permettant d'interagir avec des vidéos et avec des animations sont différentes : typiquement, dans une animation on peut vouloir passer à l'image suivante, ce qui n'a pas un grand intérêt pour une vidéo.

              Interface utilisateur, rien à voir avec le stockage et la transmission des données.

            • [^] # Re: Animation

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

              Alors, je dirais qu'en fait, techniquement, vidéo et animation c'est effectivement le même concept. En revanche, les usages sont différents, aussi différents qu'entre aller au cinéma et assister à une conférence avec projection d'un support par transparents.

              les interfaces permettant d'interagir avec des vidéos et avec des animations sont différentes : typiquement, dans une animation on peut vouloir passer à l'image suivante, ce qui n'a pas un grand intérêt pour une vidéo.

              J'ai l'impression que lorsque tu parles d'animation tu penses à des présentations à la Beamer ou Impress. Est-ce l'utilisation visée par Google avec le WebM animé ou est-ce qu'il s'agit vraiment de remplacer le GIF pour faire des pandas animés dans les pages web ?

              • [^] # Re: Animation

                Posté par . Évalué à  3 .

                Est-ce l'utilisation visée par Google avec le WebM animé

                Ils veulent animer des vidéos ??? :)

                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: Animation

                  Posté par (page perso) . Évalué à  4 . Dernière modification : le 25/11/11 à 13:48

                  Ils veulent animer des vidéos ??? :)

                  Le WebPM sera un format de vidéo animé qui permettra de naviguer entre les vidéos et de décider la durée d'affichage de chaque vidéo.

                  Ce sera le format ultime qui unifiera tous les besoins d'images sur le web :

                  • en ne mettant qu'une image par vidéo, WebPM rejoint le WebP animé ;
                  • en ne mettant qu'une seule vidéo on obtient une vidéo (remplace donc le WebM) ;
                  • et en ne mettant qu'une vidéo d'une seule image, on rejoint le WebP classique, aussi obtenu en utilisant le WebP animé avec une seule image dans l'animation.

                  C'est clair non ?

                  • [^] # Re: Animation

                    Posté par . Évalué à  6 .

                    Ils ont pas un WebMP dans leur cartons ? Le format de photos ultime : une vidéo sur pause ? ... :)

                    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: Animation

                      Posté par . Évalué à  -6 .

                      Sisi.
                      Et apres, ils rajouteront l'Extension Google et appeleront ca logiquement WebMPEG.

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: Animation

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

        Y'a la même chose dans les gifs animes, ouvre un gif de kitten animé dans gimp, si il a été 'optimisé' la frame n ne contient que les informations de modification de la frame n-1

        pour moi ce qui distingue un gif animé d'une video h264 ou webm, c'est que le "decodeur" est d'une simplicité à pleurer par rapport aux videos, et que ça tient dans 10ko de C.

        • [^] # Re: Animation

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

          et que ça tient dans 10ko de C.

          Je suis intéressé par ton décodeur WebP de 10 Ko de C, comme ça je le mettrai pour décoder WebM (qui réclame pas beaucoup plus, seul la couche conteneur change, ce qui n'est rien)
          Et au final, tu auras un WebM (sans support audio, pas grave) de même simplicité que ton décodeur WebP.

          C'est con, mais non, ce n'est pas d'un simplicité à pleurer par rapport aux vidéos, c'est quasi-pareil. La complexité, elle est juste dans la tête des gens qui veulent différencier, pas dans la tête des codeurs.

          • [^] # Re: Animation

            Posté par (page perso) . Évalué à  8 . Dernière modification : le 25/11/11 à 13:35

            Si relis mon commentaire avec attention tu verras que je parlais de GIF ANIME pas de webp, quand je mentionnais la simplicité à pleurer.

            Cela dit, par une extraordinaire coïncidence, j'étais justement en train de regarder le poids de la lib webp:

            cwebp , l'outil de compression, compilé avec la libwebp statique et strippé, pèse 87ko
            dwebp , l'outil de décompression, pèse 83ko

            On reste donc dans quelque chose d'assez léger, même si beaucoup plus sophistiqué qu'un truc qui lit les gifs, y'a des optimisations sse2/neon, y'a du multi thread dans le décodeur etc..

          • [^] # Re: Animation

            Posté par . Évalué à  2 .

            comme ça je le mettrai pour décoder WebM (qui réclame pas beaucoup plus)

            Ha, ya pas de trame I/P en WebM ? pas de techniques avancées comme le VBSMC de h264 ? plusieurs types de macroblocs à gérer ?

            • [^] # Re: Animation

              Posté par . Évalué à  1 .

              Ha, ya pas de trame I/P en WebM ?

              Je vois pas pourquoi il y aurait des paquets IP dans WebM !

              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: Animation

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

              On recommence : prend le format "video" (bref, pas le conteneur) WebP (donc WebM sans P-Frames), met le dans un conteneur WebM (bref, du matroska), ça sera pas plus dur que du WebP animé.

              Je parlais de WebM le conteneur surtout. le conteneur n'est *pas** complexe (c'est du Matroska), donc plutôt que d'utiliser l'existant (WebM auquel on "interdit" les P-Frame), on prend le WebM I-Frame qu'on met dans un autre conteneur (le truc à bidouiller pour mettre plusieurs images dans du WebP).

              Bref, au final, c'est rigolo : plutôt que de faire un "profile" WebM interdisant les P-Frames, on invente un autre conteneur. Plus de boulot pour tout le monde, mais c'est pas grave. Après, ils rajouteront l'audio à WebP...

              • [^] # Re: Animation

                Posté par . Évalué à  3 .

                Matroska has all the features you would expect of a modern A/V Container including:

                * Streamable over internet (HTTP and RTP)
                * Fast seeking in the file
                * High error recovery
                * Menus (like DVD's have)
                * Chapter entries
                * Selectable subtitle streams
                * Selectable audio streams
                * Modularly Extendable
                * Sophisticated Tagging 
                
                

                Que des trucs trop utiles à implémenter pour faire l’équivalent à peine plus poussé de cat img1.webp img2.webp > img.awebp…

                Par ailleurs, je parlais bien du format vidéo et non du conteneur. Le bitstream WebM c’est pas très éloigné de ça : http://tools.ietf.org/html/draft-bankoski-vp8-bitstream-06. Le trois quarts de ces machins est totalement inutile pour les objectifs modestes d’un WebP animé.

                Toi tu vois « je peux à partir d’un codec WebM complet faire du WebP animé », mais encore une fois c’est pas l’objectif ; l’objectif c’est de partir d’un codec WebP pour arriver à du WebP animé, et faire du cherry picking des specs de Matroska + VP8 pour arriver à ça, c’est un peu exagéré.

                • [^] # Re: Animation

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

                  Que des trucs trop utiles à implémenter pour faire l’équivalent à peine plus poussé de cat img1.webp img2.webp > img.awebp…

                  C'est grave... Le format a des éléments optionnels. C'est l'interêt d'un bon format, que le décodeur puisse zapper ce qu'il ne supporte pas.
                  Vous n'avez jamais entendu parler de profiles? plutôt que de faire un format par profile qui suffirait.

                  Le trois quarts de ces machins est totalement inutile pour les objectifs modestes d’un WebP animé.

                  Tu peux mettre alors du WebP dans un conteneur connu (au hasard : Matroska, celui de WebM), plutôt que d'en réinventer un.

                  l’objectif c’est de partir d’un codec WebP pour arriver à du WebP animé, et faire du cherry picking des specs de Matroska + VP8 pour arriver à ça, c’est un peu exagéré.

                  Pour un besoin, inventons un format. Et après, on va s'étonner que les navigateurs refusent d'implémenter 20 formats qui font la même choses mais un peu différemment".

                  Vivement le WebPM...

      • [^] # Re: Animation

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

        Pour le GIF , toutes les images sont "entières".

        Pas forcément. La première est entière, mais les suivantes peuvent être des zones rectangulaires qui viendront se "coller" à un endroit précis de l'image principale, ce qui permet d'optimiser la taille des données dans le cas où seule une partie de l'image bouge.

        * Ils vendront Usenet quand on aura fini de le remplir.

        • [^] # Re: Animation

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

          Donc des P-Frames dans le GIF, le truc "complexe" critiqué dans WebM... On s'amuse toujours bien.

          • [^] # Re: Animation

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

            Pour moi, l'intérêt du gif par rapport à une vidéo dans la balise , c'est qu'il n'y a pas de risque pour que les navigateurs y mettent des contrôles play/pause/déplacement par défaut et que ça boucle sans rien touché . C'est donc beaucoup plus simple à insérer

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

            • [^] # Re: Animation

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

              c'est qu'il n'y a pas de risque pour que les navigateurs y mettent des contrôles play/pause/déplacement par défaut et que ça boucle sans rien touché .

              Rien n'interdit techniquement aux navigateurs de mettre les boutons si ils en ont envie. Une vidéo reste une vidéo. C'est juste un choix cosmétique de leur part, qui te convient pour le moment, mais ça peut changer du jour au lendemain.

              • [^] # Re: Animation

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

                J'ai vérifié avec Firefox 8, si on met une vidéo dans la balise , elle ne démarre pas si on ne clique pas sur play. Si on veut faire une animation équivalente avec un GIF, il faut soit utiliser du JavaScript, soit laisser l'utilisateur le lancer soit même.

                Il me semble plus simple de différencier ces contenus qui n'ont pas, pour moi la même utilisation. Je préfère qu'une vidéo, qui est souvent accompagnée de son, ne se lance pas toute seule, par contre, je préfère qu'une animation qui ne contient pas de son, se lance toute seule¹

                ¹: c'est le cas général évidemment, il y a plein de contre-exemples.

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

          • [^] # Re: Animation

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

            Donc des P-Frames dans le GIF,

            Peut-être, je ne sais pas exactement ce qu'est une P-frame, mais changer juste un carré 4x4 pour faire clignoter un tout petit bout de la gif, c'était à peine une trentaine d'octets en plus dans le fichier.

            Vu les contraintes technologiques de l'époque (1989), le format GIF a quand même été une belle invention, et après les clignotements des sites à la multimania, certains artistes arrivent à en sortir des choses étonnantes : http://cinemagraphs.com//images/demo/coco-desk-429.gif per exemple.

            * Ils vendront Usenet quand on aura fini de le remplir.

            • [^] # Re: Animation

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

              Peut-être, je ne sais pas exactement ce qu'est une P-frame, mais changer juste un carré 4x4 pour faire clignoter un tout petit bout de la gif, c'était à peine une trentaine d'octets en plus dans le fichier.

              C'est l'idée même des P-Frame (différentiel par rapport à l'image précédente, à moindre coût)

              Vu les contraintes technologiques de l'époque (1989), le format GIF a quand même été une belle invention,

              Pour l'époque, sans balise vidéo, c'était une très belle invention. Comme le modem 56K était une belle invention contre le modem 33K. Mais maintenant, des hacks comme ça, ce n'est plus nécessaire. On a une balise vidéo pour la vidéo.

  • # Le nom

    Posté par . Évalué à  0 .

    C'est peut-etre tout bete, mais il y a un truc qui me dérange : le nom.
    Je me voit mal affubler mes photos, pas du tout destinées au web, d'une extension .webp
    Cela étant, ce choix de nom reflete assez bien le fait que Google ne s'interesse qu'au web, j'en prend l'exemple de l'absence de support des méta-données indiqué plus haut. Tout ce qui les intéresse, c'est la compression (et là-dessus, je suis en vrai un peu décu. Il me semblait que le jpeg2K avait déjà ce genre de gain sur le jpeg il y a 10 ans)

    • [^] # Re: Le nom

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

      Tout ce qui les intéresse, c'est la compression (et là-dessus, je suis en vrai un peu décu. Il me semblait que le jpeg2K avait déjà ce genre de gain sur le jpeg il y a 10 ans)

      L’intérêt est le risque sur les brevets, assez haut sur le JPEG-2000 (bien que pour le moment, c'est un peu le pifomètre).

      Sinon, oui, il n'y a rien de révolutionnaire, JPEG-2000 était déjà sensé remplacer JPEG sur le web et ne l'a jamais fait.

      • [^] # Re: Le nom

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

        il n'y a rien de révolutionnaire

        Si. L'alpha sur les images compressées avec pertes par exemple.

        • [^] # Re: Le nom

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

          Si. L'alpha sur les images compressées avec pertes par exemple.

          C'est qu'une couche en plus. JPEG-2000 permet un nombre illimité de couches. Juste qu'il n'y avait pas de bosin plus que ça pour que quelqu'un en fasse.

          Rien de révolutionnaire, toujours, par contre tu pourrait sortir l'argument "alpha sur les images compressées avec perte, et ce sans brevets", ça serait plus vendeur, mais toujours pas très révolutionnaire (dans le sens où il n'y a absolument rien de nouveau)

          • [^] # Re: Le nom

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

            C'est qu'une couche en plus. JPEG-2000 permet un nombre illimité de couches. Juste qu'il n'y avait pas de bosin plus que ça pour que quelqu'un en fasse.

            Sauf que personne ne l'a fait. Ce n'est pas tout d'inventer un algorithme de compression et un format : il faut également le faire évoluer selon la demande, se bouger pour le promouvoir, coder pour qu'il soit pris en charge, et le laisser libre. JPEG-2000 a échoué sur tous ces points.

            Ce n'est pas l'algorithme qui est révolutionnaire, mais plutôt la volonté de le répandre, et les actions concrètes pour cela. D'une façon plus extrême, c'est comme lorsqu'une boîte invente un appareil innovant et intéressant mais ne le commercialise pas — et ne publie pas non plus les plans — : ça ne sert à rien, ça n'apporte rien à la société.

            • [^] # Re: Le nom

              Posté par . Évalué à  -7 .

              Marrant ca, quand ca parle d'ipad, etonnament tout ce que tu viens de dire n'a plus aucune importance et on entend plus que "eud'facons, zont rien invente".

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: Le nom

                Posté par . Évalué à  -5 .

                Ya quand même une ptite différence entre commercialiser un produit fermé et promouvoir un format ouvert…

                • [^] # Re: Le nom

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

                  Tiens, hop, ça nous plait pas, on invente une excuse qui n'a rien à voir avec le sujet pour dire que c'est différent, pas une révolution. Euh... C'est quoi le rapport avec la révolution? C'est une révolution uniquement si la révolution va dans ton sens? On n'a pas la même définition...

                • [^] # Re: Le nom

                  Posté par . Évalué à  -8 .

                  Non, je vois pas ce que ça va changer dans ce cas.

                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: Le nom

                Posté par . Évalué à  4 .

                Personne n'a dis que WebP était révolutionnaire juste qu'il est bien.

                Quand on sort un truc en disant c'est révolutionnaire il vaut mieux que ça le soit si on n'accepte pas les critères.

                Quand on sort quelque chose en indiquant juste « nous on a un format de vidéo qui nous semble pas mal, on pense qu'il peut faire un bon format d'image et on intègre ça à notre format d'image », alors oui tu peut dire qu'ils n'ont rien révolutionner et qu'ils n'ont fait qu'un travail d'intégration (on prend un format déjà existant et on y ajout des techno actuelles faites ailleurs).

                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: Le nom

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

                  Personne n'a dis que WebP était révolutionnaire juste qu'il est bien.

                  Tu pourrais lire un peu... On a réagit, ce n'est pas dans le vide.
                  Le lien direct si il faut : https://linuxfr.org/nodes/88383/comments/1294170

                  Quand on sort un truc en disant c'est révolutionnaire il vaut mieux que ça le soit si on n'accepte pas les critères.

                  Google n'a pas dit que c'est révolutionnaire, mais Tanguy oui. Donc bon, c'est lui qu'on critique.

                  et qu'ils n'ont fait qu'un travail d'intégration (on prend un format déjà existant et on y ajout des techno actuelles faites ailleurs).

                  C'est surtout un n-ieme format, sans concertation. Alors pour l'image, à la limite ça permet d'avoir le niveau de JPEG-2000 (c'est trop rigolo de comparer à JPEG, peur de se comparer au bon format proprio existant?) avec moins de problème de droits (mais j'ai un doute : est-ce que Google s'engage à me défendre si jamais je suis attaqué? Non. Donc j'ai autant de risque sur WebP que sur JPEG-2000). Pour la vidéo, hop un autre conteneur, c'est lourd, on en a déjà suffisamment des conteneurs, ils auraient mis WebP dans du Matroska comme ils font pour WebM que ça aurait été plus simple pour tout le monde.

            • [^] # Re: Le nom

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

              Ce n'est pas l'algorithme qui est révolutionnaire, mais plutôt la volonté de le répandre, et les actions concrètes pour cela. D'une façon plus extrême, c'est comme lorsqu'une boîte invente un appareil innovant et intéressant mais ne le commercialise pas — et ne publie pas non plus les plans — : ça ne sert à rien, ça n'apporte rien à la société.

              Très fort : Apple ne fait rien de révolutionnaire, mais Google fait de la révolution. J'espère que la prochaine fois que quelqu'un critiquera Apple car il n'a rien fait de révolutionnaire, tu réagiras en disant que la révolution tient dans la façon de l'amener.

              D'après ton argument, Google fait quelques révolutions, Apple fait des révolutions permanentes (et eux, ça marche, car pour le moment WebP ne marche pas plus que ça à part chez Google, comme WebM)

              Bref, ça me fait bien sourire que les gens (pas que toi, je te rassure) change les arguments suivant ce qui leur plait (pour d'autres raisons), sans accepter d'appliquer les mêmes critères pour tous.

    • [^] # Re: Le nom

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

      l'exemple de l'absence de support des méta-données

      Exemple caduque : WebP prend en charge les méta-données XMP.

      Tout ce qui les intéresse, c'est la compression

      Non. L'alpha sur les images compressées avec pertes, ce n'est pas un luxe, c'est une fonctionnalité qui comble un véritable besoin. Typiquement, mon avatar.

  • # arguments

    Posté par . Évalué à  2 .

    Autant j'ai été convaincu par certains arguments : meilleur compression gestion séparée de la transparence.
    Autant je trouve :

    il est également intéressant de disposer d'un format unique adapté à tout type d'image matricielle, qui peut éviter aux béotiens de s'interroger — et de se tromper — sur le format approprié.

    discutable.
    Avoir un seul format pour des problématiques différentes (lossless, lossy, animation) n'est pas trop dans la philosophie unix. Quoique l'on puisse faire du jpeg lossless.
    De plus, avoir un seul format ne dispense pas de comprendre la différence entre lossless et lossy ; car il faut bien que l'utilisateur indique sa préférence à un moment (choix d'un format) ou à un autre (option d'un format).
    ça me parait même plus confus dans une seul format (WebP+Lossless / WebP+lossy) que dans deux (PNG / JPEG).

    Enfin, comme dit plus haut : pas convaincu du nom.

    • [^] # Re: arguments

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

      En fait les noms des outils laissent entendre que le format lossless s'appellerait webpll , alors que le format lossy s'appelle webp . Actuellement les sources des deux formats sont completements independantes, meme si elles vivent dans le même dépot.

      Les sources du format lossless sont d'ailleurs très concises , 1500 lignes pour le decodeur seul, 5600 pour le decodeur, l'encodeur et l'outil de conversion png <-> webpll , et il n'a pas de dependance sur la zlib (contrairement à libpng, qui compte plus de 40000 lignes de sources)

      • [^] # Re: arguments

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

        par contre en terme de vitesse de decompression c'est pas encore ça, pour l'instant la decompression du webpll est 5x plus lente que celle du png , (mais c'est une version alpha il y a peut etre une marge de progression conséquente).

        • [^] # Re: arguments

          Posté par . Évalué à  3 .

          pour l'instant la decompression du webpll est 5x plus lente que celle du png

          ah, je m'attendais bien à un truc dans le genre... merci d'avoir indiqué cette valeur. Et pour du webp, en comparaison à du jpg, ça donne quoi ?

          Un seul format d'image, ça me semble bien, surtout si ça combine le meilleur de chacun. Il n'y a qu'à avoir une option avec un échelle de compression, indiquant la qualité approximative à l'utilisateur : s'il veut du sans perte, il met l'échelle au maximum, sinon ça compresse avec de la perte. Ça me semble simple, et plus facile à expliquer que le PNG, JPG, GIF etc...

          Je suis impatient de trouver cela généralisé dans les outils qu'on utilise habituellement (gimp, inkscape, firefox...)

          Par contre je reste également dubitatif sur le nom qui n'est pas très sexy...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: arguments

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

            J'ai pas comparé avec le jpg, mais par contre le webp en qualité 90 est a peu pres comparable au png pour le temps de decompression, genre 15% ou 20% plus lent seulement. C'est plus rapide en qualité moindre et plus lent en qualité supérieure, mais je n'ai pas la moindre idée de comment se situe jpg par rapport à png. Je n'ai pas non plus vu d'acceleration notable avec sse2 dans webp, par rapport à la version c basique.

            Pour webpll je pense que le code n'a pas encore été pleinement optimisé, d'ailleurs c'est du c++ alors que webp est en C, et on dirait que les images webpll n'ont pas le moindre magic number dans le header, j'imagine que google voudra corriger ça quand il auront une version moins experimentale

          • [^] # Re: arguments

            Posté par . Évalué à  4 .

            Le souci d'une echelle unique, c'est qu'elle ne prends pas en compte le type d'image. Pour un dessin plein d'aplats, un png compressé sera moins lourd et de meilleure qualité qu'un jpeg. Comment expliquer à quelqu'un que son image de qualité 10 (le haut de l'echelle, en png/wepll) est plus petite que celle de qualité 9 (en jpeg/webp)?

            • [^] # Re: arguments

              Posté par . Évalué à  1 .

              Comment expliquer à quelqu'un que son image de qualité 10 est plus petite que celle de qualité 9 ?

              Ce n'est pas la taille qui compte :)

              Quand on voit que certains sont capables d'envoyer 50 Mo de pièces jointes (plusieurs jpg en 6000 x 8000) ou d'envoyer du BMP, j'ai l'impression que peu de monde sera dérangé par cela.

              Et ça ne les dérange pas non plus d'avoir du jpg ouvert et réenregistré 10 x de suite avec de plus en plus d'artefacts, sans s'alarmer que la qualité est bien en deça de la taille finale de fichier.

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: arguments

              Posté par . Évalué à  7 . Dernière modification : le 29/11/11 à 03:34

              Comment expliquer à quelqu'un que son image de qualité 10 (le haut de l'echelle, en png/wepll) est plus petite que celle de qualité 9 (en jpeg/webp)?

              Clairement, un bon format se devrait d'aller jusqu'à 11.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.