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 🚲 Tanguy Ortolo (site web personnel) . É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 Yves Bourguignon . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
http://www.cyclim.se/
[^] # Re: Journal
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 25 novembre 2011 à 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 zebra3 . Évalué à 5.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Merci de votre compréhension.
[^] # Re: Journal
Posté par BAud (site web personnel) . Évalué à -6.
J'ai corrigé mon commentaire ;-) pas réveillé ce matin :p
[^] # Re: Journal
Posté par Zenitram (site web personnel) . É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 claudex . Évalué à -1.
Tu peux aussi envoyer un mail sur la liste des modérateurs pour qu'ils éditent tes commentaires.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal
Posté par Zenitram (site web personnel) . É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 barmic . Évalué à 3.
C'est écris où ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal
Posté par Kekun (site web personnel, Mastodon) . Évalué à 6.
Dans ton cœur.
[^] # Re: Journal
Posté par BAud (site web personnel) . É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.
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 co
quille é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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal
Posté par B16F4RV4RD1N . É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 Sufflope (site web personnel) . Évalué à 8.
Ah oui c'est pratique, ça, l'InternetP.
[^] # Re: spéciale dédicace
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à -3.
Tu veux parler du iNternetP, sans doute... :-p
# Webp semble incomplet...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 25 novembre 2011 à 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 :
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 :
Google a une vision 100% web du monde, ce qui est bien, mais pas top.
[^] # Re: Webp semble incomplet...
Posté par Sufflope (site web personnel) . Évalué à 8.
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 LeBouquetin (site web personnel, Mastodon) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ç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 devnewton 🍺 (site web personnel) . Évalué à 10.
Mozilla rejette depuis longtemps le support de MNG qui possède pourtant toutes les qualités requises...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Webp semble incomplet...
Posté par monde_de_merde . Évalué à 3.
Geocities et les gifs animés c'était mieux à vent !
[^] # Re: Webp semble incomplet...
Posté par Grunt . É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 gnuzer (site web personnel) . Évalué à 3.
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 tape . É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 djano . É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 BohwaZ (site web personnel, Mastodon) . É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 matthieu bollot (site web personnel, Mastodon) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 fearan . É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 BohwaZ (site web personnel, Mastodon) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 Zenitram (site web personnel) . Évalué à -2.
Oh l'usine à gaz...
[^] # Re: Webp semble incomplet...
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 Zenitram (site web personnel) . É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 zebra3 . Évalué à 3.
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 Zenitram (site web personnel) . É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 barmic . Évalué à 1.
Parce qu'ils compte le mettre dans les APN ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Webp semble incomplet...
Posté par zebra3 . É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 barmic . Évalué à 1.
A oui excuse-moi, je parlais d'appareils photo pas de webcam.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Webp semble incomplet...
Posté par zebra3 . É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 Frank-N-Furter . Évalué à 4.
Il parlait d'appareils qui font des photos de qualitay.
Depending on the time of day, the French go either way.
[^] # Re: Webp semble incomplet...
Posté par barmic . Évalué à 6.
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é.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Gimp supporte également WebP...
Posté par LeBouquetin (site web personnel, Mastodon) . É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 neil . É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 zebra3 . Évalué à 6.
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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Cool encore un format !
Posté par Larry Cow . Évalué à 10.
Après il y a des malades partout
[^] # Re: Cool encore un format !
Posté par pasScott pasForstall . É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 zebra3 . É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . É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. »
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Format d'image ultime
Posté par nud . É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 claudex . Évalué à 10.
Je cite le commentaire auquel tu réponds
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Format d'image ultime
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Format d'image ultime
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Format d'image ultime
Posté par ʭ ☯ . Évalué à 1.
Parce que le décodeur hardware aura besoin de beaucoup plus de puissance?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Format d'image ultime
Posté par Zenitram (site web personnel) . É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . É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.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Format d'image ultime
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
???
Définis « polyvalent » pour voir ?
???
Définis « latitude de retouche »…
Euuuuh… C'est du français ça ?
[^] # Re: Format d'image ultime
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . É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.
Je n'ai quasiment jamais eu la moyenne dans cette matière là. Ça se lit tant que ça ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Format d'image ultime
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
À 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.
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 BB . Évalué à 1.
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 Zenitram (site web personnel) . Évalué à 1.
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 BB . Évalué à 4.
Je viens de regarder, 32 bits par canal depuis 2009, grâce à GEGL.
[^] # Re: Format d'image ultime
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . É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éelleflottante). D'où d'ailleurs l'éventuel intérêt pour des formats compressés avec pertes mais un peu plus riches en bpc.« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Format d'image ultime
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
Absolument pas ; toujours mes lacunes en expression écrite…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Format d'image ultime
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Format d'image ultime
Posté par Larry Cow . É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 Julien Jorge (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 9.
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 Grunt . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Animation
Posté par Julien Jorge (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Animation
Posté par GuieA_7 (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Animation
Posté par GuieA_7 (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Animation
Posté par GuieA_7 (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Animation
Posté par GuieA_7 (site web personnel) . Évalué à 2.
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.
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 !
Je ne connaissais pas ça a l'air sympa merci.
[^] # Re: Animation
Posté par nerbrume . É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 Zenitram (site web personnel) . Évalué à 5.
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 nerbrume . É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 Zenitram (site web personnel) . Évalué à 1.
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.
De rien.
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 Moonz . Évalué à 2.
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 Grunt . É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 🚲 Tanguy Ortolo (site web personnel) . É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 :
[^] # Re: Animation
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 25 novembre 2011 à 13:41.
Ç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'.
Interface utilisateur, rien à voir avec le stockage et la transmission des données.
[^] # Re: Animation
Posté par Grunt . Évalué à 3.
décrie ;)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Animation
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 25 novembre 2011 à 13:37.
baud123, tu peux corriger ma honteuse erreur s'il te plaît ? ;-)
[^] # Re: Animation
Posté par patrick_g (site web personnel) . Évalué à 3.
Suis pas baud123 mais c'est fait.
[^] # Re: Animation
Posté par BAud (site web personnel) . Évalué à 2.
http://sensmotdire.gnunux.info/plaire.html fait :-) plaît idem pour paraît d'ailleurs :D
[^] # Re: Animation
Posté par Julien Jorge (site web personnel) . Évalué à 1.
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 barmic . Évalué à 3.
Ils veulent animer des vidéos ??? :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Animation
Posté par Julien Jorge (site web personnel) . Évalué à 4. Dernière modification le 25 novembre 2011 à 13:48.
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 :
C'est clair non ?
[^] # Re: Animation
Posté par barmic . Évalué à 6.
Ils ont pas un WebMP dans leur cartons ? Le format de photos ultime : une vidéo sur pause ? ... :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Animation
Posté par pasScott pasForstall . É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 Troy McClure (site web personnel) . É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 Zenitram (site web personnel) . Évalué à -2.
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 Troy McClure (site web personnel) . Évalué à 8. Dernière modification le 25 novembre 2011 à 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 Moonz . Évalué à 2.
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 barmic . Évalué à 1.
Je vois pas pourquoi il y aurait des paquets IP dans WebM !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Animation
Posté par Moonz . Évalué à 2.
En plus je voulais dire B/P…
[^] # Re: Animation
Posté par Zenitram (site web personnel) . Évalué à 1.
WebM (le format vidéo, pas le conteneur) ne supporte pas les B-Frames.
[^] # Re: Animation
Posté par Zenitram (site web personnel) . É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 Moonz . Évalué à 3.
Matroska has all the features you would expect of a modern A/V Container including:
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 Zenitram (site web personnel) . Évalué à 0.
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.
Tu peux mettre alors du WebP dans un conteneur connu (au hasard : Matroska, celui de WebM), plutôt que d'en réinventer un.
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 Tonton Th (site web personnel, Mastodon) . Évalué à 2.
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.
[^] # Re: Animation
Posté par Zenitram (site web personnel) . Évalué à 2.
Donc des P-Frames dans le GIF, le truc "complexe" critiqué dans WebM... On s'amuse toujours bien.
[^] # Re: Animation
Posté par claudex . É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
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Animation
Posté par Zenitram (site web personnel) . Évalué à 2.
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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Animation
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
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.
[^] # Re: Animation
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est l'idée même des P-Frame (différentiel par rapport à l'image précédente, à moindre coût)
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 nerbrume . É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 Zenitram (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Si. L'alpha sur les images compressées avec pertes par exemple.
[^] # Re: Le nom
Posté par Zenitram (site web personnel) . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
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 pasScott pasForstall . É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 navaati . É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 Zenitram (site web personnel) . É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 pasScott pasForstall . É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 barmic . É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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le nom
Posté par Zenitram (site web personnel) . Évalué à 0.
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
Google n'a pas dit que c'est révolutionnaire, mais Tanguy oui. Donc bon, c'est lui qu'on critique.
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 Zenitram (site web personnel) . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Exemple caduque : WebP prend en charge les méta-données XMP.
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 steph1978 . Évalué à 2.
Autant j'ai été convaincu par certains arguments : meilleur compression gestion séparée de la transparence.
Autant je trouve :
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 Troy McClure (site web personnel) . É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 Troy McClure (site web personnel) . É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 B16F4RV4RD1N . Évalué à 3.
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 Troy McClure (site web personnel) . É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 nerbrume . É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 B16F4RV4RD1N . Évalué à 1.
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 Antoine . Évalué à 7. Dernière modification le 29 novembre 2011 à 03:34.
Clairement, un bon format se devrait d'aller jusqu'à 11.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.