🚲 Tanguy Ortolo a écrit 12240 commentaires

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 ?

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.

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

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 ?

Bon, alors je continue. Une initiative citoyenne fermée, pour moi c'est mal fichu, donc je zapperais tout simplement.

Personnellement, j'en pense que c'est très fermé et opaque. Les buts ne sont pas clairs, d'ailleurs. Je trouve ça plutôt inquiétant, en fait.

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

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.

Il est fort probable que Mandriva ai décidé un jour d'économiser 12 euros par an en prenant un sous domaine ( y a pas de petite économie ).

Ou plutôt qu'ils aient décidé de rationnaliser tout ça. C'est complètement crétin, les noms de domaines multiples à la mode SNCF : voyages-sncf.com, 12-25-sncf.com, senior-sncf.com, etc.

il n'y a rien de révolutionnaire

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

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.

Merci de votre compréhension.

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.

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

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.

ou « flims »

http://www.cyclim.se/

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.

Et puis j'aime bien m'amuser avec GIMP surtout. Et j'aime bien l'autosatisfaction récursive aussi. :-)

Je me souviens également d'un professeur que j'ai eu, environ 60 ans

Ça fait long, soixante ans d'études avec le même professeur, non ? Comment ça, je fais exprès de mal comprendre ? o:-)

PS : Bonne maîtrise du détourage mon cher Tanguy, ton avatar prend une autre dimension !

Merci ! C'est un hackergotchi que j'avais réalisé pour le Planet Debian il y a quelques mois, que j'ai ensuite repris sur Jabber, et que je viens seulement de penser à utiliser ici. Mais j'attends avec impatience une large prise en charge du format WebM qui serait plus approprié pour disposer d'une compression avec pertes et canal alpha.

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

Ne me parlez du changement d'utilisateur, ce truc venant de Windows, ergonomique, lent (et dépendant de l'environnement de bureau). Ctrl+Atl+Fx et on change de session, à l'ancienne et très efficace ;-)

La dernière fois que j'ai utilisé cette fonctionnalité de GNOME, en pratique ce qu'elle faisait c'était précisément ça : lancer un second serveur X avec un nouveau GDM sur une nouvelle console.

La fourchette.

On est d'accord, c'est tout de même vachement mieux que les baguettes. À condition d'en avoir une.

En fait, pour être précis, ce qu'fdm peut faire, c'est prendre du courrier de n'importe où (POP, IMAP, mbox, Maildir, entrée standard, NNTP), et, selon des critères de ton choix (recherche dans les en-têtes, dans le corps, résultat d'une commande…), l'envoyer n'importe où (le jeter, le conserver, l'envoyer à une commande, l'envoyer par SMTP, l'écrire dans un fichier, dans une mbox, dans un Maildir…).

Donc pour ton cas, il peut prendre le courrier dans le Maildir INBOX, et selon certains critères, le mettre dans d'autres Maildirs.

Le gigo-octet est au gigaoctet ce que le gigowatt est au gigawatt ?

Ça me semble osé — et méchant — comme commentaire. En revanche, si j'ignore ce qui a amené à la création de Geeknode, je trouve personnellement que créer encore un nouveau réseau IRC est dommageable en effet.

En effet, le protocole IRC a été conçu pour fonctionner sous la forme d'un unique réseau en anneau, un peu comme USENET je suppose. Des schismes ont eu lieu, mais le résultat est que la multiplication des réseau est pénible pour les utilisateurs.

Depuis, le protocole XMPP a été conçu et permet de faire à peu près les mêmes choses, mais dans un mode plus acentré et fédéré.