🚲 Tanguy Ortolo a écrit 12689 commentaires

Il y a plus simple, sans aller déterrer GIF : une animation WebP. WebP, pas WebM : ça se met bien dans une img.

Yes, en tant que moule, je veux ajouter mon merci car je lis pas mal linuxfr et c'est une bonne source d'information et il y a un certain sens de communauté (même si les commentaires sont parfois assez brusques).

C'est triste ton avis sur les commentaires.

Évidemment, je ne teste pas HEIF, ce format ne me concerne pas (je n'ai pas de logiciel pour en produire).

Au temps pour moi, il y a bien un compresseur fourni avec libheif. Sur les icônes de ×ばつ128 ça donne :

• en HEIF sans perte : 580 kio en 1,8 s.

HEIF ne fait pas non plus le poids, en tout cas pour ce type d'image. Pas génial en poids, pas génial en temps de calcul. Je m'en réjouis.

et à presque 2Mo en jpg

Ça, pour des icônes, ce n'est pas du tout pertinent. Pas de transparence en JPEG, c'est inutilisable.

Allez, à mon tour.

Compression de 44 icônes en ×ばつ64. Ce sont les icônes d'applications du thème hicolor :

• en PNG d'origine : 296 kio ;
• en PNG optimisé (et quantifié...) par pngnq, donc avec destruction : 172 kio ;
• en GIF, donc avec destruction : 156 kio ;
• en WebM quasi-sans perte : 156 kio ;
• en AVIF sans perte : 304 kio ;
• en JPEG XL quasi-sans perte : 152 kio.

Avec des icônes en ×ばつ128 :
* en PNG d'origine : 688 kio ;
* en PNG optimisé (et quantifié...) par pngnq, donc avec destruction : 368 kio en 1,5 s ;
* en GIF, donc avec destruction : 384 kio en 4 s avec ImageMagick ;
* en WebM quasi-sans perte : 340 kio en 1,4 s ;
* en AVIF sans perte : 824 kio en 3,2 s ;
* en JPEG XL quasi-sans perte : 324 kio en 1,1 s.

Visiblement, AVIF ne fait pas le poids, en taux de compression comme en temps de calcul. JPEG XL bat tout le monde dans ces deux domaines.

Évidemment, je ne teste pas HEIF, ce format ne me concerne pas (je n'ai pas de logiciel pour en produire).

(sans compter qu'une mise à jour de firmware des APN est toujours possible et Nikon ou Sony n'y manqueront pas s'ils constatent la mise en avant d'un autre format)

Ça tout de même je n'y compterais pas trop. Vous mettez souvent à jour votre appareil photo vous ? Vous avez déjà vu une mise à jour d'ailleurs ?

Le fait d'être prisonnier d'un format problématique imposé par le fabricant d'un appareil photo ne t'oblige pas à le défendre. Ça sent le syndrome de Stokholm.

D'ailleurs, concrètement, si tu veux passer des photos à quelqu'un d'autre, tu risque de devoir les convertir au préalable en WebM ou en AVIF, avec perte supplémentaire, voire augmentation de taille.

Si ton fabricant d'appareil photo les enregistrait directement en WebM ou en AVIF, tu n'aurais pas ce problème-là, donc tu es en droit de leur en vouloir d'avoir choisi un format problématique. S'il les enregistrait en JPEG XL, tu aurais ce problème pendant un ou deux ans, puis plus aucun problème au fur et à mesure que ce format commencera à être lisible partout.

Mais à part ça, HEIF c'est super en fait, ça permet de continuer à avoir des problèmes de formats malgré les super initiatives vraiment ouvertes telles que AVIF et JPEG XL. Heureusement qu'il y a des fabricants pour choisir ce format, on s'ennuierait sinon.

Voilà, c'est refait. J'avais oublié de surtout ne mettre aucune métadonnée dans le PNG.

Donc, avec une image de ×ばつ16 avec quelques traits de noir sur fond transparent :

• GIF : 77 octets,
• PNG : 127 octets,
• WEBP : 64 octets,
• AVIF : 537 octets,
• JPEG XL : 137 octets.

Et pour comparaison, le même genre de dessin trivial (trois lignes et un polygone) en SVG optimisé par Inkscape :

• SVG optimisé : 537 octets,
• SGV optimisé puis gzippé : 290 octets.

Il en ressort que pour des icônes :
* GIF est encore très intéressant ;
* WEBP est un peu plus intéressant, c'est le seul à être plus efficace de GIF ;
* PNG se défend, JPEG XL aussi ;
* AVIF est obèse en comparaison ;
* SVG est trop verbeux pour que ce soit pertinent avec de si petites tailles, de toute façon le rendu serait trop flou pour être intéressant.

Pas mal. Un genre de MJPEG 2000 en somme. :-)

À noter que ce choix technique vraisemblablement été dicté par la possibilité de compresser sans perte, justement. Donc si ça devait évoluer, à moins qu'on ne trouve un vrai format vidéo sans perte, ça pourrait être remplacé par un autre format d'image proposant cette fonctionnalité, donc WebP, AVIF, HEIF ou JPEG XL. Bon, plutôt HEIF ou JPEG XL, parce que dans WebP il y a Web, ce qui ne fait pas très sérieux, et l'AVIF ça vient d'une Open Media Alliance, dans laquelle il y a open, ce qui ne fait pas très sérieux non plus pour des gens du cinéma.

Pour sortir les images, pdfimages -all.

Je vois, c'est un truc d'initié que le commun des mortels ne peut pas comprendre. Aucun intérêt d'en parler dans ce cas.

À refaire, j'ai dû me planter quelque part. :-)

C'est sûr que si on sort les photos brutes pour les développer soi-même, on peut librement choisir son format. Et là, choisir HEIF, c'est, euh, un choix idéologique, pas un choix pratique.

C'est comme quand on choisit d'utiliser un truc libre parce que c'est libre et pas parce que c'est mieux. Sauf que là c'est l'inverse, choisir volontairement HEIF, c'est choisir d'utiliser un truc pourri de brevets pour cette raison et non parce qu'il est mieux (parce qu'il ne l'est pas, le concurrent est juste plus performant, a plus de fonctionnalité et déjà plus largement supporté).

Ah, je ne dis pas qu'HEIF a certainement un avenir assuré comme format de niche, pour les fabricants d'appareil photo, et pour les photographes qui subissent ce choix. Ça me rappelle un peu des trucs comme Memory Stick par exemple. Ou mieux, Compact Flash, qui a quand même tenu vachement longtemps dans des appareils réflex alors que le reste du monde était passé aux cartes SD.

Seulement, sur le Web, HEIF a peu de chances de percer. Il n'arrive déjà pas à percer face à un concurrent plus ancien (AVIF), et il y a déjà un concurrent plus récent (JPEG XL) qui, à peine arrivé, est déjà mieux supporté.

Sauf que justement, dans un PDF on peut très bien stocker seulement des images matricielle. Ça a assez peu d'intérêt... sauf pour les numérisations en très haute définition de document en noir et blanc. Le format idéal pour ça, c'est le DjVu, mais peu de gens peuvent le lire. Le second format idéal, c'est JBIG2, mais à peu près personne ne peut le lire... sauf si c'est mis dans un document PDF !

Désolé, je mentionnais ici PDF dans un usage précis qui consiste à encapsuler une image. Matricielle ou vectorielle d'ailleurs.

PDF sert couramment à bien plus que cela. Mais, en matière de stockage d'image, si vous voulez intégrer un dessin vectoriel dans un document composé en LaTeX, il va vous falloir la stocker en PDF, justement. :-)

Tiens, tant que j'y pense, c'est une fonctionnalité de JPEG XL, ça, de permettre l'intégration de canaux additionnels qui représentent autre chose que de la couleur ou de la transparence. Je n'ai pas regardé le détail, mais ils doivent à l'évidence être exclus des optimisations psycho-visuelles, ou pouvoir l'être, et il devrait être possible de les compresser avec ou sans perte.

Ça ne prend toujours pas de majuscule. Certains travaillent dans l'informatique libre, dans les travaux publics ou dans la chirurgie reconstructrice sans revendiquer une majuscule.

Oui, c'est conçu pour ça. Et je viens d'essayer, sur une image JPEG de 1,9 Mio, j'obtiens une image JPEG XL de 1,5 Mio sans perte supplémentaire.

C'est le gros intérêt du JPEG XL, la fonctionnalité qui semble anecdotique mais qui tue, en fait : on peut prendre une ensemble de millions de photos en JPEG, et bourrinement transcoder tout ça en JPEG XL sans risquer d'avoir des remords.

Mieux encore, JPEG XL est capable de se transcoder vers JPEG, toujours sans perte. Voire même, encore mieux, à condition d'avoir stocké les métadonnées d'origine, de reconstruire exactement le JPEG d'origine ! Évidemment, le résultat est plus gros, mais ça permet de servir du JPEG à ceux qui ne savent pas lire le JPEG XL.

Personnellement, je ne suis pas du tout surpris qu'il faille prendre des précautions lorsqu'on utilise un format d'image compressée pour stocker quelque chose qui n'est pas une image.

Les formats d'image sont faits pour permettre de restituer une image de façon à ce que nous la percevions de façon acceptable (avec perte), indiscernable de l'originale (avec pertes imperceptibles), ou identique à l'originale (sans perte perceptible ni mesurable).

Si on commence à utiliser ça pour autre chose que des images, c'est du détournement de la fonction du format, et on commence à devoir travailler contre ses optimisations.

À noter que WebP dispose carrément d'un mode « presque sans perte », qui applique des modifications mineures aux couleurs des pixels, censément imperceptibles, pour que ça se compresse mieux.

Conserver l'intégralité de l'image numérique est une priorité quand on travaille dans l'Art,

Quand on travaille dans l'art, sans majuscule. Travailler dans l'Art, c'est le domaine des artiseurs dans l'œuvre de Robin Hobb. :-)

Pour TIFF, c'est compliqué.

Pour XCF, ce n'est pas à proprement parler un format d'image raster, c'est un format de fichier de travail de logiciel de traitement d'image raster. En particulier, il permet de stocker des calques et des modes de superposition de ces derniers : c'est une fonctionnalité qui n'a aucun intérêt pour stocker simplement une image, mais qui est indispensable pour stocker sans perte un travail graphique matriciel.

Le format XCF n'est aucunement en concurrence avec PNG, JPEG et compagnie. En revanche, il existe un format standard, ouvert, qui peut être considéré pour un stockage interopérable de travaux graphiques : OpenRaster.

Certainement. Pour obtenir un truc facile à distribuer, on repassera en revanche.

Oui alors forcément, à part JPEG et PNG, on n'aura jamais de format vraiment universel, si on entend par là supporté par absolument tout.

Par contre, WebP est suffisamment répandu pour qu'on puisse s'attendre à :

• un support par tous les navigateurs, tous les afficheurs et outils de traitement d'image ;
• pouvoir ouvrir des bugs pour les logiciels qui ne le supporte pas, et que ces bugs ne soient pas immédiatement fermés parce que c'est un format exotique dont tout le monde se moque.

Bon, vous auriez un exemple, histoire qu'on puisse comparer sérieusement ?

Pour info, avec une image de ×ばつ16, toute transparente avec quelques traits de noir pur, j'obtiens :

• un PNG optimisé de 1 kio ;
• un GIF de 767 octets ;
• un WebP de 62 octets.