🚲 Tanguy Ortolo a écrit 12334 commentaires

(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×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×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.

Ouille, ça pue ça. Je me demande quel est l'intérêt de Google là-dedans. Espérons qu'ils y reviendront si tout le monde s'y met.

Après tout, Mozilla a mis trois ans avant de considérer l'ajout de WebP à leurs logiciels. Là, Google ont foncé pour intégrer JPEG XL dans Chrome, puis ont fait marche arrière. Au moins, ils sont techniquement prêts à le remettre.

Alors non, pas pour des icônes toutes petites. Du SVG, ça reste du XML, assez verbeux.

Comparé à une image matricielle assez grande, c'est imbattable. Mais pour une icône, on prend moins de place en matriciel correctement compressé en fait.

Tiens, j'avais oublié la chronologie. HEIF a mis huit ans pour convaincre Apple, quelques fabricants d'appareils photo et zéro acteur du Web. AVIF a mis quatre ans pour convaincre tout le monde logiciel. JPEG XL a mis moins d'un an pour commencer à convaincre une partie du monde logiciel, à un rythme qui rappelle celui de WebP.

Après, qui gagne, on s'en moque un peu. Lorsqu'on a un choix de format à faire, la seule question à se poser, c'est : quel format répond à mes besoins et a le plus de chances d'être toujours lisible dans dix ans. Et actuellement, la réponse, c'est généralement WebP (pris en charge partout), AVIF (presque partout), peut-être JPEG XL (sera sans doute pris en charge partout, mais pas encore), mais certainement pas HEIF qui n'est pas lisible et ne le sera peut-être jamais sur certains systèmes.

Le fait de pouvoir lire du HEIF, c'est très bien, surtout quand on a un appareil photo qui sort ce format-là. Mais ce n'est pas la même chose lorsqu'on est amené à choisir volontairement un format pour une image qu'on vient de produire ou qu'on veut stocker à long terme.

Ça ne me dit rien, mais ça a l'air cousin de la compression par ondelettes de JPEG 2000. Parce que contrairement à JPEG qui compresse par blocs, la compression basée sur une transformée en ondelettes travaille sur l'image entière, avec des fonctions qui n'ont de valeur significative que localement. En conséquence, il me semble qu'il n'y a pas vraiment de notion de pixel dans ce contexte théorique.

Exact, j'avais oublié. Et d'ailleurs, PNG permet aussi de faire du gris ou du RGBA sur 16 bits par canal. Si un modérateur a le temps de corriger :

Publié en 1996 par le W3C, le format PNG a été conçu pour remplacer GIF, qui souffrait de limitations techniques et de problèmes de brevets. Il permet de compresser sans perte une image avec une palette de 8 ou 256 couleurs, en niveau de gris sur 1 à 16 bits ou en RVB sur 8 ou 16 bits par canal, avec une transparence optionnelle par canal alpha sur 8 ou 16 bits.

C'est peut-être une niche, mais je ne sais pas si d'autres formats sont sur cette niche et font mieux que le PNG là-dedans.

Est-ce que WebP ne pourrait pas faire mieux ? Même sans palette, une image avec très peu de couleurs pourrait être très efficace à compresser. Je n'ai pas essayé, mais ce serait intéressant à vérifier. Si ce n'est pas le cas, clairement, une image avec peu de couleurs gagnerait à rester en PNG.