Des formats d'image

Posté par  (site web personnel) . ÉditĂ© par orfenor, vmagnin, bobble bubble, ted et Ltrlg. ModĂ©rĂ© par bobble bubble. Licence CC By‑SA.
Étiquettes :
94
24
juin
2023
Graphisme/photo

Les formats d’image classiques datent des annĂ©es 1990 : aprĂšs le format GIF en 1987, sont apparus le JPEG en 1992, le PNG en 1996 et le SVG en 1998. Leur adoption progressive s’est faite dans le contexte de la premiĂšre guerre des navigateurs.

Ces formats couvrant Ă  peu prĂšs tous les usages, les choses en sont restĂ©es lĂ  pendant plus de dix ans. Mais le paysage a commencĂ© Ă  changer dans les annĂ©es 2010, avec l’introduction d’un nouveau format d’image moderne, WebP, pensĂ© pour rĂ©pondre Ă  tous les besoins courants et pouvoir supplanter Ă  la fois JPEG et PNG. Depuis, les nouveautĂ©s s’enchaĂźnent, avec HEIF en 2015, AVIF en 2019 et JPEG XL en 2022.

Voici de quoi y voir plus clair.

Sommaire

Formats d'images matricielles

GIF – Graphics Interchange Format

PubliĂ© en 1987, avant mĂȘme l’invention du Web, le format GIF permet de compresser sans perte une image avec une palette comptant au maximum 256 couleur et une transparence tout-ou-rien.

Le format GIF a longtemps Ă©tĂ© le seul format largement supportĂ© permettant de stocker des animations, et il est restĂ© utilisĂ© pour cela pendant une trentaine d’annĂ©es. Aujourd’hui, cette fonctionnalitĂ© est disponible avec le format WebP, et GIF peut enfin prendre une retraite bien mĂ©ritĂ©e.

GIF est pris en charge par tous les navigateurs et probablement tous les logiciels d’affichage et de traitement d’image. En revanche, ce format ne prĂ©sente plus aucun intĂ©rĂȘt pour un usage courant, puisqu’il a Ă©tĂ© complĂštement supplantĂ© par PNG, qui est lui-mĂȘme ringard.

JPEG – Joint Photographic Experts Group

PubliĂ© en 1992 comme norme ISO, le format JPEG sert Ă  compresser des photos avec pertes. Il permet de reprĂ©senter des images en niveau de gris sur 8 bits ou en RVB sur 24 bits. Il ne supporte aucun mode de transparence. Ce format peut ĂȘtre utilisĂ© au sein d’un document PDF, ce qui est utile pour la composition de documents avec des images, par exemple en LaTeX compilĂ© directement en PDF.

JPEG est pris en charge par tous les navigateurs et tous les logiciels d’affichage et de traitement d’image. Ceci dit, ce format ne prĂ©sente plus aucun intĂ©rĂȘt pour la plupart des usages courants, et peut ĂȘtre remplacĂ© par WebP pour les nouvelles images.

PNG – Portable Network Graphics

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.

Comme JPEG, ce format peut ĂȘtre utilisĂ© dans un document PDF.

PNG est une recommandation du W3C, Ă©galement reprise sous la forme d’une RFC puis d’une norme ISO. Il est pris en charge par tous les navigateurs et tous les logiciels d’affichage et de traitement d’image. Ceci dit, ce format ne prĂ©sente plus aucun intĂ©rĂȘt pour la plupart des usages courants, et peut ĂȘtre remplacĂ© par WebP pour les nouvelles images.

Il a Ă©galement Ă©tĂ© Ă©tendu par deux formats d’animation qui ont longtemps souffert d’une querelle qui explique l’utilisation persistante de l’antique format GIF :

  • MNG – Multiple-image Network Graphics – initialement supportĂ© par les logiciels Mozilla ;
  • APNG – Animated PNG – aujourd’hui largement supportĂ©.

JPEG 2000

PubliĂ© en
 2000, ce format visait Ă  remplacer JPEG, avec une compression plus performante. L’accĂšs payant Ă  sa spĂ©cification, ainsi que des soupçons de problĂšmes de brevets, ont largement contribuĂ© Ă  la trĂšs faible adoption de ce format.

Ce format a pourtant un intĂ©rĂȘt anecdotique, puisqu’à l’instar de JPEG et PNG, il peut ĂȘtre utilisĂ© dans un document PDF.

Le format JPEG 2000 est assez peu connu et donc supporté par peu de logiciels en dehors de ceux spécifiquement conçus avec le souci de pouvoir traiter des images dans un maximum de formats.

JBIG2 – Joint Bi-level Image Group

PubliĂ© Ă©galement en 2000, ce format sert Ă  compresser avec ou sans pertes des images en noir et blanc. Il s’agit ici de vrai noir et blanc, et non de niveaux de gris.

Ce rĂŽle trĂšs spĂ©cifique limite beaucoup son utilisation, mais il reste intĂ©ressant pour stocker avec une efficacitĂ© redoutable des textes numĂ©risĂ©s en trĂšs haute dĂ©finition. Il peut Ă©galement ĂȘtre intĂ©grĂ© dans un document PDF, ce qui est trĂšs utile pour l’archivage de documents.

Comme JPEG 2000, JBIG2 est assez peu connu et supporté par peu de logiciels.

WebP

En 2010, Google est venu bousculer ce paysage à peu prùs stable, en proposant un format moderne, conçu pour s’imposer comme une solution universelle.

DĂ©rivĂ© du format vidĂ©o VP8, WebP est donc un format ouvert, qui permet de compresser de façon efficace avec ou sans perte, en RVB sur 24 bits, avec un canal alpha optionnel (Ă  noter que ce dernier peut ĂȘtre compressĂ© sans perte mĂȘme pour une image compressĂ©e avec pertes). Il permet Ă©galement de stocker des animations.

Aujourd’hui, WebP est pris en charge par tous les navigateurs et par la majoritĂ© des logiciels d’affichage et de traitement d’image. Il peut dĂ©jĂ  ĂȘtre considĂ©rĂ© comme un format universel largement utilisable.

HEIC – HEVC dans un conteneur HEIF

Le format HEIF – High Efficiency Image File Format – est un conteneur, principalement conçu pour le stockage d’images compressĂ©es avec HEVC — High Efficiency Video Codec. L’ensemble est publiĂ© depuis 2015. Il permet de compresser avec ou sans perte, avec un canal alpha optionnel, et supporte les animations.

Ce format est une norme ISO, issue du travail du groupe MPEG, et souffre de problùmes de brevets. Il n’est pris en charge par aucun navigateur et seulement par certains logiciels d’affichage et de traitement d’image.

Ce format a peu de chance de rĂ©ellement s’imposer, en dehors du cercle de certains environnements logiciels propriĂ©taires spĂ©cifiques comme celui d’Apple.

AVIF – AV1 Image File Format

PubliĂ© en 2019 par l’Alliance for Open Media fondĂ©e par Amazon, Google, Cisco, Microsoft, Mozilla et Netflix, ce format utilise le conteneur HEIF pour stocker des images compressĂ©es avec AV1. Comme les autres formats modernes, il permet de compresser avec ou sans pertes les images en niveaux de gris et en couleur, avec un canal alpha optionnel, et supporte les animations. Il permet Ă©galement l’intĂ©gration d’un profil de couleurs et le stockage de grandes gammes de couleurs, jusqu’à 12 bits par couleur.

Ce format est ouvert et disponible sans problùme de brevet. Il est pris en charge par tous les navigateurs modernes et par certains logiciels d’affichage et de traitement d’image.

Il est peut-ĂȘtre un peu tĂŽt pour en juger, mais ce format pourrait s’imposer avec une prise en charge assez large.

JPEG XL

FinalisĂ© en 2022, ce format a Ă©tĂ© conçu par le groupe JPEG pour remplacer le format JPEG premier du nom. Il supporte l’ensemble des fonctionnalitĂ©s modernes : niveaux de gris, couleur, alpha optionnel et animations, et apporte des fonctionnalitĂ©s utiles pour des usages plus avancĂ©s, telles que le support des couleurs en CMJN, des espaces de couleurs larges ou encore les grandes gammes dynamiques. Ce format prĂ©sente Ă©galement une fonctionnalitĂ© qui apparaĂźt particuliĂšrement intĂ©ressante pour la compression d’images existantes, puisqu’il permet de recompresser sans nouvelles pertes une image JPEG, avec Ă©videmment un gain d’espace de stockage.

C’est un format ouvert, apparemment disponible sans problĂšme de brevets. Il commence Ă  ĂȘtre pris en charge par des navigateurs, Ă  savoir Firefox nightly et Safari, ainsi que par bon nombre de logiciels d’affichage et de traitement d’image dans leurs versions rĂ©centes.

En clair, ce format est un peu trop jeune pour qu’on puisse compter sur une large prise en charge, mais cela viendra sans doute dans les annĂ©es Ă  venir.

Formats d’images vectorielles

EPS – Encapsulated PostScript

Conçu par Adobe, le format PostScript encapsulĂ© est dĂ©rivĂ© du PostScript, qui a connu son heure de gloire il y a une ou deux dĂ©cennies, pour le stockage d’images destinĂ©es Ă  ĂȘtre intĂ©grĂ©es dans un flux de production de documents.

Il Ă©tait notamment utile pour intĂ©grer des images vectorielles (ou non !) dans un document LaTeX. Il est aujourd’hui largement supplantĂ© pour ces usages par le format PDF.

PDF – Portable Document Format

Inutile de prĂ©senter le format PDF, Ă©galement conçu par Adobe, normalisĂ© et trĂšs largement rĂ©pandu. Je prĂ©ciserai simplement qu’il permet entre autres de stocker des images vectorielles avec transparence. Il est utile dans cet usage pour stocker des schĂ©mas destinĂ©s Ă  ĂȘtre intĂ©grĂ©s dans un document, par exemple un document LaTeX compilĂ© directement en PDF.

En revanche, son usage habituel Ă©tant plutĂŽt celui du stockage de documents de plusieurs pages, il n'est pas utilisable pour intĂ©grer des dessins dans une page Web. Il est bien supportĂ© par tous les navigateurs modernes, mais plutĂŽt dans une optique d’intĂ©gration de document externe.

SVG – Scalable Vector Graphics

Le format SVG a Ă©tĂ© publiĂ© en 1998 par le W3C. C’est le format standard d’images vectorielles, utilisĂ© nativement par nombre de logiciels de dessin. Il est supportĂ© par tous les navigateurs modernes et par la plupart des logiciels d’affichage d’image. Il est supportĂ© par tous les logiciels de dessin vectoriel libre, et probablement Ă©galement par les logiciels de dessin propriĂ©taire puisqu’il serait assez indĂ©cent de fournir un logiciel de dessin qui ne puisse pas au minimum importer ce format standard.

Outils

Pour convertir des images d’un format matriciel à un autre, vous pouvez utiliser :

Pour stocker des images matricielles JPEG, PNG ou JPEG 2000 en PDF, sans recodage, vous pouvez utiliser img2pdf. Je ne connais pas de solution simple pour stocker une image JBIG2 dans un document PDF. Pour convertir des dessins vectoriels en PDF, le plus simple est d’utiliser la fonctionnalitĂ© d’export PDF de son logiciel de dessin vectoriel. Celle d’Inkscape est utilisable en ligne de commande.

Conclusion

Photos

Pour stocker une photo existante, gardez l’image JPEG existante. Si vous avez des contraintes de stockage, utilisez JPEG XL. Pour publier une photo ou une crĂ©ation, oubliez JPEG et utilisez WebP. Ou, si vous voulez faire moderne, AVIF.
N’utilisez pas HEIC, ce format n’a pas Ă©tĂ© correctement conçu pour s’imposer et fait dĂ©jĂ  partie des perdants.

Photos détourées

Pour stocker et diffuser une photo avec de la transparence (votre visage ?), utilisez WebP. Ou, si vous voulez faire dans la modernitĂ©, AVIF. Oubliez PNG, ce format n’est pas adaptĂ© et n’était utile dans ce domaine qu’avant l’arrivĂ©e de WebP qui a l’avantage d’ĂȘtre vraiment adaptĂ© Ă  cet usage.

Dessins, BD, 


Pour stocker une image existante, vous pouvez bien garder le PNG existant. Si vous avez des contraintes de stockage, utilisez JPEG XL. Pour publier une image existante ou une création, utilisez WebP ou AVIF. Oubliez PNG, WebP en mode sans perte est juste mieux.

Dessins et schémas vectoriels

Pour le stockage comme pour la publication d’images vectorielles, le format standard SVG est presque toujours la meilleure option, sinon la seule. Si vous voulez utiliser un schĂ©ma dans un document LaTeX, le mieux est de l’exporter en PDF, en conservant le SVG original. Oubliez le PostScript encapsulĂ©, ce format a Ă©tĂ© complĂštement supplantĂ© par PDF pour ses cas d’usage.

Aller plus loin

  • # WebP sans perte et exact (car tous les fichiers images ne codent pas rouge/vert/bleu/transparent)

    Posté par  (site web personnel) . Évalué à 10.

    DĂ©rivĂ© du format vidĂ©o VP8, WebP est donc un format ouvert, qui permet de compresser de façon efficace avec ou sans perte, en RVB sur 24 bits, avec un canal alpha optionnel (Ă  noter que ce dernier peut ĂȘtre compressĂ© sans perte mĂȘme pour une image compressĂ©e avec pertes). Il permet Ă©galement de stocker des animations.

    WebP est vraiment trùs efficace ! Pour des images à 8 bit par canal, si WebP est pris en charge, mieux vaut utiliser Webp que JPEG ou PNG, pour ces deux cas d’usage.

    Exemple avec une texture de ciel Ă©toilĂ© du jeu Unvanquished (JPEG, WebP avec perte, PNG) :

    comparaison Jpeg, PNG, WebP

    Mais ! Chose importante Ă  savoir pour ceux qui voudraient utiliser WebP ! Par dĂ©faut l’outil cwebp avec l’option -lossless ne produit pas d’image sans perte ! Ah bon ? Oui ! Si vous affichez une image, le rendu est exactement le mĂȘme, pixel par pixel, couleur par couleur, MAIS, des donnĂ©es non visibles (pour un simple rendu) peuvent avoir Ă©tĂ© perdues. Pour faire un vĂ©ritable WebP sans perte avec l’outil cwebp il faut utiliser les options -lossless -exact.

    Mais qu’est ce que cette diablerie ? đŸ˜±ïž

    Par dĂ©faut cwebp -lossless peut dĂ©truire des donnĂ©es si la transparence ne les rendraient pas visibles. Ça peut poser problĂšme si on veut Ă©diter une image
 et changer la transparence. Ça peut aussi poser problĂšme si on utilise WebP, pour autre chose que de la reprĂ©sentation de couleur et de transparence.

    Comment ça les canaux rouge, vert, bleu, et transparence ne codent pas nĂ©cessairement les canaux rouge, vert, bleu et transparence ? đŸ€šïž

    Par exemple, dans les jeux vidĂ©os, on va utiliser des formats d’image parce que c’est parfait pour reprĂ©senter des matrices de donnĂ©es. Le premier image sera la texture, donc une « image » telle qu’on se l’imagine, mais on va aussi utiliser des formats d’images pour stocker d’autres donnĂ©es. Par exemple on va coder dans un « fichier image » additionnelle la façon dont lumiĂšre se rĂ©flĂ©chit en telle ou telle partie de la texture : si c’est du bĂ©ton, on va mettre une valeur pour dire que la surface ne brille pas beaucoup, si c’est du mĂ©tal poli, on va mettre une valeur pour dire que la surface brille beaucoup. Ainsi dans le jeu, on va pouvoir afficher la couleur du bĂ©ton et du mĂ©tal, mais aussi appliquer sur ces couleurs des effets de reflets. Des « images » de ce type il en existe plein, pour coder la rĂ©flexion de chaque pixel, mais aussi des coordonnĂ©es de normale (X, Y, et Z dans R, V, B en gĂ©nĂ©ral), ou l’élĂ©vation de texture (pour coder une illusion de dĂ©formation, pixel par pixel). Sauf que voilĂ , si on peut par exemple coder des coordonnĂ©es de normale X, Y, et Z dans R, V, et B, on peut aussi coder l’élĂ©vation dans le canal alpha, et alors, le canal alpha ne code pas de la transparence, et on ne peut supposer que les coordonnĂ©es X, Y, Z de la normale peuvent ĂȘtre ignorĂ©es parce que la profondeur est grande, ou encore, que la rugositĂ© du pixel peut ĂȘtre ignorĂ©e parce que la mĂ©tallicitĂ© du pixel est Ă©levĂ©e ou que sais-je encore en fonction de telle ou telle convention de stockage. đŸ™ƒïž Il est donc possible de stocker plein de choses dans le canal alpha qui ne sont pas des informations de transparence, et plein d’autres choses dans les canaux R, V, B qui ne sont pas des couleurs, mais qui sont d’autres composantes du mĂȘme pixel. đŸ§ïž

    Et donc, au final, puisque les images dans les jeux vidĂ©os ont plus que quatre canaux (rouge, vert, bleu, transparence, addition de rouge, addition de vert, addition de bleu, normale X, normale Y, normale Z, Ă©lĂ©vation, rugositĂ©, mĂ©tallicitĂ©, occlusion, etc.), et que les formats d’images n’ont que 4 canaux, bah on doit stocker tous ces canaux pour une seule image dans plusieurs « fichiers images ». On peut donc se retrouver avec 2, 3, 4 fichiers images pour une seule image, mais un seul canal alpha utilisĂ© pour coder de la transparence, et une collections de canaux RVB qui ne codent pas de la couleur. đŸ«Ł

    Quand il n’y a pas besoin de format d’image sans perte dans un jeu vidĂ©o, les jeux vidĂ©os privilĂ©gient d’autres formats que le WebP ou le JPEG, comme les formats DXT qui sont transfĂ©rĂ©s compressĂ© dans la mĂ©moire de la carte graphique, et stockĂ©s compressĂ©s dans la mĂ©moire de la carte graphique. Mais dans un dĂ©pĂŽt de source de donnĂ©es de jeu vidĂ©o, on veut des format sans perte, donc si quelqu’un choisit de faire du WebP pour « giter » les images sources de son jeu libre, il devra utiliser cwebp -lossless -exact. Et s’il utilise PNG, ne pas oublier de cocher la case « Enregistrer les valeurs de couleur pour les pixels transparents » dans GIMP, pour la mĂȘme raison.

    D’ailleurs il faudra que je vĂ©rifie si GIMP propose la mĂȘme option « Enregistrer les valeurs de couleur pour les pixels transparents » pour WebP. đŸ˜€ïž

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: WebP sans perte et exact - Et la transparence par couleur ?

      Posté par  . Évalué à 4.

      Merci pour ton observation. Du coup je m'interroge sur la notion de canal, et notamment de canal de transparence.

      Si j'ai bien compris, un canal de transparence dans un format d'image, c'est une valeur de transparence appliquée qui s'applique à l'identique à tous les canaux de couleur.

      Est-ce qu'on ne voudrait pas avoir une valeur de transparence par canal de couleur justement ? Comme pour un verre coloré, indiquer que ça ne lasse passer qu'une partie du rouge par exemple.

    • [^] # Re: WebP sans perte et exact

      Posté par  . Évalué à 6.

      Tu n'utilises pas QOI ?

    • [^] # Re: WebP sans perte et exact

      Posté par  . Évalué à 4.

      La façon dont tu compares les images JPEG et WEBP n'a aucun sens vu que le paramĂštre qualitĂ© ne fonctionne pas de la mĂȘme façon entre les deux formats (et mĂȘme entre deux compresseurs JPEG).
      Comparer deux formats d'images n'est pas facile. Pour le faire simplement il faudrait que tu compares l'aspect d'images compressĂ©es de poids Ă©gal. Ça resterait injuste et comparerait en fait les implĂ©mentation des algos de compression plutĂŽt que les formats (c'est Ă  dire que tu comparerait deux logiciels), mais on peut trouver raisonnable de le faire ainsi pour retrouver l'expĂ©rience de monsieur (et madame) tout le monde.

      Peu d'outils de compression JPEG présentent toutes les options possibles. LibTurboJpeg, Mozjpeg et Adept-compressor, permettent de jouer avec plus d'options, mais il faut les comprendre. Squoosh te permettra de tester facilement presque toutes les possibilités.

      • [^] # Re: WebP sans perte et exact

        Posté par  (site web personnel) . Évalué à 4.

        Comparer avec le paramÚtre "qualité" n'a effectivement pas de sens, mais avec l'image agrandie qu'il a fournie on voit bien que sur le jpeg il y a plus d'artefacts de compression et qu'ils sont disgracieux.

        Un LUG en Lorraine : https://enunclic-cappel.fr

        • [^] # Re: WebP sans perte et exact

          Posté par  . Évalué à 2.

          on voit bien que sur le jpeg il y a plus d'artefacts de compression et qu'ils sont disgracieux

          MĂȘme si le JPEG crĂ©e toujours des artefacts, lĂ  encore ça prouve assez peu de chose puisque d'une selon le logiciel et les paramĂštres de compression ça peut beaucoup changer, et deux les artefacts ne sont pas censĂ©s ĂȘtre perceptibles en vision "normale", et trois JPEG n'est pas conçu pour prĂ©server la qualitĂ©.
          Je ne dis pas ça pour argumenter gratuitement (mĂȘme si je reconnais avoir tendance Ă  dĂ©fendre bec et ongle mes arguments), mais parce que ça fait des annĂ©es que j'optimise des images pour le web et que je m'intĂ©resse donc Ă  la comparaison du poids, Ă©tant admis que les conditions de visionnage ne sont pas trĂšs bonne (mobile en lumiĂšre artificielle, ordi portable sur les genoux ou Ă©cran au rendu standard et non calibrĂ©).

    • [^] # Re: WebP sans perte et exact

      Posté par  (site web personnel) . Évalué à 6.

      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.

      • [^] # Re: WebP sans perte et exact

        Posté par  (site web personnel) . Évalué à 8.

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

        C’est pour cela que je ne parle que du « WebP sans perte » et du « PNG sans perte ». Je ne discute pas des formats avec pertes dont les algorithmes supposent un usage bien prĂ©cis et donc une seule opĂ©ration de rendu de couleur pour Ă©laborer les optimisations. Si le format a besoin de supposer un usage prĂ©cis, c’est peut-ĂȘtre qu’on ne fait dĂ©jĂ  plus du « sans perte ».

        MĂȘme pour pour sauvegarder une image pensĂ©e pour ĂȘtre affichĂ©e sur le web, un graphiste peut vouloir un format « sans perte » qui ne dĂ©truise pas les pixels transparents, parce qu’il peut vouloir Ă©diter la transparence plus tard pour rĂ©vĂ©ler la couleur (ou laisser Ă  un autre la possibilitĂ© de le faire).

        Quand aux autres canaux discutĂ©s, ce ne sont pas vraiment « autre choses que des images », ou du moins tout n’est pas « autre chose que des images ». Dans les cas que j’ai Ă©voquĂ©s, tous les pixels de tous les canaux codent des donnĂ©es pour les mĂȘmes pixels que les canaux rouge, vert, bleu et alpha, de la mĂȘme maniĂšre que le canal alpha code l’opacitĂ©. Ce sont des donnĂ©es supplĂ©mentaires pour ces mĂȘmes pixels, ce sont donc des canaux supplĂ©mentaires pour ces images.

        L’opacitĂ© stockĂ©e dans le canal alpha n’est dĂ©jĂ  pas « une image » en soit.

        Comme l’a relevĂ© marzoul, on peut imaginer coder l’opacitĂ© avec 3 canaux alpha : rouge, vert, et bleu, pour par exemple ne laisser passer que le rouge par transparence et rester opaque aux autres couleurs, plutĂŽt que de supposer de n’avoir un seul canal de transparence Ă©gal Ă  toutes les couleurs.

        Les canaux rouge, vert, bleu sont pensĂ©s pour de l’affichage opaque sur Ă©cran. Le canal alpha a surtout Ă©tĂ© pensĂ© pour le web, pour se passer de CSS dans la majeure partie des cas (dĂ©tourage, opacitĂ©). Mais ce canal alpha fait des suppositions trĂšs fortes : que tous les canaux de couleur soient identiques en alpha, et que l’opĂ©ration de mĂ©lange soit toujours la mĂȘme. Certains formats comme le GIF n’avaient qu’1 seul bit de transparence, donc ça ne servait qu’au dĂ©tourage. Le web avait besoin de plus que ça, le canal alpha rĂ©pond vite-fait au besoin, mais pour une seule fonction, avec un seul canal pour toutes les couleurs, « ça fera l’affaire ».

        Les formats d'image sont faits pour [
]

        Ces formats d’image ne sont faits que pour le web Ă  l’époque d’HTML 4. FTFY =)

        Si on commence à utiliser ça pour autre chose que des images, c'est du détournement de la fonction du format,

        Ce n’est pas du dĂ©tournement de la fonction du format, c’est un ajout de donnĂ©es et d’opĂ©rations. MĂȘme avec une image qui code des donnĂ©es rouge, vert, bleu dans les canaux rouge, vert, bleu, on peut destiner ces couleurs rouge, vert, bleu Ă  autre chose qu’une seule et mĂȘme opĂ©ration de mĂ©lange. Par exemple on peut faire une addition. Une « carte d’addition », c’est exactement ça : une image avec des canaux rouge, vert, bleu, mais l’opĂ©ration utilisĂ©e n’est pas celle utilisĂ©e par le navigateur quand on fait <img src="image.png"/>, les couleurs seront additionnĂ©es.

        Il Ă©tait courant, Ă  une Ă©poque oĂč les formats d’images avec canal alpha n’étaient pas autant rĂ©pandus, de stocker le canal alpha dans une autre image que celle qui stocke les canaux rouge, vert, bleu. Par exemple certains jeux peuvent distribuer les canaux rouge, vert, bleu, dans une image JPEG, puis le canal alpha dans une seconde image JPEG.

        Il existe des formats avec pertes qui n’attribuent pas la mĂȘme prĂ©cision pour chaque canal. Par exemple on peut imaginer un format couleur et opacitĂ© de seulement 16 bits (au lieu de 32 bits) qui attribuerait 3 bits pour le rouge, 3 bits pour le vert, 2 bits pour le bleu, et 8 bits pour l’opacitĂ©. Il est courant d’échanger les canaux, par exemple de stocker le vert dans l’alpha si on veut 8 bits de prĂ©cision pour le bleu. Ces formats d’image avec pertes fournissent Ă©ventuellement des mĂ©tadonnĂ©es qui renseignent ces Ă©changes de canaux.

        Voici quelques exemples d’attribution de canaux avec des textures du jeu Xonotic :

        ivy.jpg ivy_alpha.jpg ivy_gloss.jpg ivy_norm.jpg
        JPEG Rouge: Couleur Rouge JPEG Rouge: Opacité JPEG Rouge: Spécularité Rouge JPEG Rouge: Normale X
        JPEG Vert: Couleur Vert JPEG Vert: Spécularité Vert JPEG Vert: Normale Y
        JPEG Bleu: Couleur Bleu JPEG Bleu: Spécularité Bleu JPEG Bleu: Normale Z
        black-tiles-mossy_norm.jpg black-tiles-mossy_norm.jpg black-tiles-mossy_norm_alpha.jpg
        JPEG Rouge: Couleur Rouge JPEG Rouge: Normale X JPEG Rouge: Profondeur
        JPEG Vert: Couleur Vert JPEG Vert: Normale Y
        JPEG Bleu: Couleur Bleu JPEG Bleu: Normale Z
        pk02_floor07.tga pk02_floor07_gloss.tga pk02_floor07_norm.tga
        TGA Rouge: Couleur Rouge TGA Rouge: Spécularité Rouge TGA Rouge: Normal X
        TGA Vert: Couleur Vert TGA Vert: Spécularité Vert TGA Vert: Normal Y
        TGA Bleu: Couleur Bleu TGA Bleu: Spécularité Bleu TGA Bleu: Normal Z
        TGA Alpha: Opacité TGA Alpha: Profondeur
        pk02_light02a.tga pk02_light02a_glow.tga pk02_light02a_gloss.tga pk02_light02a_norm.tga
        TGA Rouge: Couleur Rouge TGA Rouge: Addition Rouge TGA Rouge: Spécularité Rouge TGA Rouge: Normal X
        TGA Vert: Couleur Vert TGA Vert: Addition Vert TGA Vert: Spécularité Vert TGA Vert: Normal T
        TGA Bleu: Couleur Bleu TGA Bleu: Addition Bleu TGA Bleu: Spécularité Bleu TGA Bleu: Normal Z
        TGA Alpha: Profondeur

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: WebP sans perte et exact

          Posté par  (site web personnel) . Évalué à 4. DerniĂšre modification le 26 juin 2023 Ă  22:01.

          Petite correction :

          - par exemple de stocker le vert dans l’alpha si on veut 8 bits de prĂ©cision pour le bleu
          + par exemple de stocker le bleu dans l’alpha si on veut 8 bits de prĂ©cision pour le bleu

          ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: WebP sans perte et exact

      Posté par  (site web personnel) . Évalué à 7.

      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.

  • # JPEG-XL

    Posté par  . Évalué à 8.

    Merci pour cet Ă©tat des lieux.

    JPEG-XL permet de recompresser sans nouvelles pertes une image JPEG, avec Ă©videmment un gain d’espace de stockage.

    L'inverse est Ă©galement vrai, ce qui peut ĂȘtre rassurant au cas oĂč JPEG-XL ne se dĂ©velopperait pas.

    Pour info, Darktable est capable d'exporter en JPEG-XL et Digikam est capable de créer/éditer des métadonnées dans du JPEG-XL (en le configurant pour utiliser Exiftool plutÎt que Exiv2). En revanche, je ne connais aucun gestionnaire de photos sous Android prenant en charge le JPEG-XL (il y a juste Jpeg-XL Viewer qui ne permet rien d'autre que l'affichage d'une image dans ce format).

    • [^] # Re: JPEG-XL

      Posté par  . Évalué à 3.

      Oui merci pour la dĂ©pĂȘche.
      Tout comme les systĂšmes de fichiers, j'ai tendance Ă  prendre les formats d'images comme acquis et relativement immuables, c'est bien d'avoir un rappel.

      Pour la publication web, on a pas fini de rigoler:
      https://kurtextrem.de/posts/modern-way-of-img

    • [^] # Re: JPEG-XL

      Posté par  (Mastodon) . Évalué à 10.

      Un truc qui n'a pas Ă©tĂ© mentionnĂ© dans cette dĂ©pĂȘche, c'est que Google tente de tuer JPEG-XL via l'arrĂȘt de son support par Google Chrome/chromium:
      https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

      • [^] # Re: JPEG-XL

        Posté par  (site web personnel) . Évalué à 4.

        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.

        • [^] # Re: JPEG-XL

          Posté par  (Mastodon) . Évalué à 4.

          Accessoirement webp n'est pas si universel que ça. Je me suis rendu compte la semaine derniÚre que sans afficher d'erreur durant l'upload, le client matrix Element ne semblait pas afficher l'étiquette d'un salon en webp.

          • [^] # Re: JPEG-XL

            Posté par  (site web personnel) . Évalué à 4.

            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.
        • [^] # Re: JPEG-XL

          Posté par  . Évalué à 4.

          Oui enfin au delà des polémiques, ils ont aussi produit une comparaison assez fouillée entre ces codecs, comme tu le dis plus bas, WebP ne gagne pas dans tous les domaines, mais on peut se demander si JPEGXL en vaut la peine (pas taper, je pense que oui).

          • [^] # Re: JPEG-XL

            Posté par  . Évalué à 4. DerniĂšre modification le 26 juin 2023 Ă  13:11.

            mais on peut se demander si JPEGXL en vaut la peine (pas taper, je pense que oui).

            En ce qui me concerne, la rĂ©ponse est oui. MĂȘme si je ne vais Ă©videmment pas me prĂ©cipiter pour convertir mes dizaines de milliers de jpeg en jpeg-xl, les tests que j'ai pu faire en convertissant sans perte du jpeg en jpeg-xl montrent un gain de place qui multipliĂ© par le nombre est consĂ©quent. Comme l'opĂ©ration inverse est possible sans perte, ça fait moins peur que de tout convertir en webp.

            Et je développe mes nouvelles photos en jpeg-xl directement.

            • [^] # Re: JPEG-XL

              Posté par  . Évalué à 3.

              Je voulais dire comparé à WebP

            • [^] # Re: JPEG-XL

              Posté par  (site web personnel) . Évalué à 3.

              Tu confirmes qu'on gagne de place en jpeg-xl en partant d'un jpeg et sans ajouter des pertes? J'imaginais que dans ce cas précis, le changement de format n'apportait pas de gain de place, comme si on réorganisait juste les données dans un nouveau conteneur.

              Un LUG en Lorraine : https://enunclic-cappel.fr

              • [^] # Re: JPEG-XL

                Posté par  (site web personnel) . Évalué à 10.

                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.

              • [^] # Re: JPEG-XL

                Posté par  . Évalué à 3.

                C'est une des killer feature pour le Web (avec le progressive decoding): jpeg-xl est capable de faire une conversion sans perte depuis un jpeg avec des gains de 20% (et donc on peut revenir vers le jpeg d'origine).

                https://cloudinary.com/blog/legacy_and_transition_creating_a_new_universal_image_codec#legacy_friendly_jpeg_xl

                Donc c'est un gros plus pour toutes les images existantes sur le web qu'il serait trÚs facile à convertir sans perte de qualité.

        • [^] # Re: JPEG-XL

          Posté par  . Évalué à 6.

          Rappel: Une réponse à leur choix
          https://cloudinary.com/blog/the-case-for-jpeg-xl

          Espérons qu'ils y reviendront si tout le monde s'y met.

          AprÚs leur décision, des personnes appartenant à des "entreprises" telles que Adobe, Facebook, Shopify, The Guardian, FFmpeg, nvidia, Intel,
 ont posté des commentaires sur le bug tracker de Chrome ( https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 ) qu'ils attendaient que le codec soit promu stable plutÎt que retiré car ils voulaient l'utiliser.

          Depuis, pas de réponse de la part de Google

          Apparemment, celui qui a pris la décision de retirer le support dans Chrome serait un des développeur de Webp.

          Je ne connais la chronologie mais peut-ĂȘtre Ă©tait-ce aussi car Webp2 Ă©tait prĂ©vu mais Google a annoncĂ© que Webp2 ne sera pas publié 

          Mozilla a dĂ©cidĂ© d'ĂȘtre neutre sur le sujet :(

          Apple a annoncĂ© le support dans Safari donc on espĂšre que ça va faire pencher la balance et accĂ©lĂ©rer l'adoption


          Liens annexes:
          * Une discussion sur jpex-xl pour une gallery open-source sur Android(avec des infos)
          * https://jpegxl.info/
          * Progressive Jpeg-xl (impressionant)

  • # comparaison n'est pas raison

    Posté par  (site web personnel) . Évalué à 5.

    Merci pour cette synthÚse, c'est beaucoup plus digeste qu'un tableau sur wikipedia comme Comparison_of_graphics_file_formats ;-)

    et en plus j'aime bien la conclusion, qui oriente vers des formats appropriĂ©s selon le cas d'usage (qui peut ĂȘtre bien plus complexe, en fonction des besoins — comme le souligne illwiecz< dans le premier commentaire ci-dessus)

  • # Avis sur HEIF

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Ton avis sur HEIF me parait assez radical et infondé, outre Apple, il a été choisi également par Sony et Canon qui est un poids lourd dans la photographie numérique et nikon commence à s'y mettre aussi avec son nouveau Z8, les logiciels suivront Gimp et Darktable reconnaissent déjà HEIF.

    https://www.funix.org mettez un manchot dans votre PC

    • [^] # Re: Avis sur HEIF

      Posté par  (site web personnel) . Évalué à 8.

      Ton analyse semble pertinente, mais en effet, j'espÚre que ça ne s'imposera pas car le problÚme de licence va nous retomber dessus.

      Il faudrait vraiment qu'il ai un avantage technique majeur, ce qui n'est pas exposé ici. Sinon, ça sent la tentative de domination du marché par les acteurs installés.

      Je me trompe? J'espĂšre.

      • [^] # Re: Avis sur HEIF

        Posté par  (site web personnel, Mastodon) . Évalué à 1. DerniĂšre modification le 25 juin 2023 Ă  15:00.

        Ce journal est bien trop simpliste pour se faire une rĂ©elle idĂ©e et n'est pas digne d'une dĂ©pĂȘche
        J'avais Ă©crit il y a quelque temps un journal sur le format HEIF.

        https://www.funix.org mettez un manchot dans votre PC

        • [^] # Re: Avis sur HEIF

          Posté par  . Évalué à 4.

          Eh oh c'est l'été hein, on écrit ça entre deux vagues. C'est pratique, pas encyclopédique.

    • [^] # Re: Avis sur HEIF

      Posté par  . Évalué à 1.

      Pas d'avis sur la question.
      Mais j'ai eu l'occasion d'en croiser et que c'est "pris en charge" par Windows depuis quelques temps
      https://apps.microsoft.com/store/detail/extensions-dimage-heif/9PMMSR1CGPWG?hl=fr-fr&gl=fr

    • [^] # Re: Avis sur HEIF

      Posté par  (site web personnel) . Évalué à 10. DerniĂšre modification le 26 juin 2023 Ă  10:20.

      Ton avis sur HEIF me parait assez radical et infondé

      Infondé, et puis quoi encore ? Alors, voyons un peu les fondements en question.

      HEIF est :

      • minĂ© de brevets problĂ©matiques ;
      • pris en charge par aucun navigateur ;
      • pris en charge par certains outils d'affichage et de traitement d'image.

      AVIF est :

      • libre de brevets problĂ©matiques ;
      • pris en charge par tous les navigateurs ;
      • pris en charge par certains outils d'affichage et de traitement d'image.

      JPEG XL est :

      • conçu et promu comme successeur de JPEG Ă  long terme ;
      • libre de brevets problĂ©matiques ;
      • pris en charge par certains navigateurs (c'est tout jeune, ça commence Ă  peine) ;
      • pris en charge par certains outils d'affichage et de traitement d'image (dont la liste est dĂ©jĂ  plus longue que celle de HEIF).

      Je m'avance peut-ĂȘtre, mais HEIF a l'air clairement d'ĂȘtre promu Ă  un avenir aussi radieux que la connectique Thunderbolt. Il a peut-ĂȘtre convaincu quelques acteurs, mais cĂŽtĂ© navigateurs, c'est trĂšs, trĂšs mal parti, aucun n'a suivi. En face, on a un concurrent qui a dĂ©jĂ  rĂ©ussi Ă  s'imposer (AVIF, bon courage pour le rattraper vu ce qui arrive ensuite). Je doute qu'HEIF rĂ©ussisse Ă  percer dans quelques annĂ©es, puisqu'il y en a un autre qui dĂ©bute et est bien parti pour s'imposer encore plus (JPEG XL, qui est vraiment conçu avec ce qu'il faut pour remplacer JPEG Ă  long terme).

      En matiÚre de conseil de formats, je maintiens qu'aujourd'hui, il n'y a aucune raison, lorsqu'on enregistre une image aprÚs création ou retouche, de choisir ce format, AVIF est juste mieux, parce qu'il est lisible partout. Et si donc, vous avez enregistré une image en AVIF, et que dans deux ans, HEIF s'impose (et que JPEG XL échoue, ce qui m'étonnerait beaucoup), ça n'aurait aucune importance, AVIF restera lisible.

      • [^] # Re: Avis sur HEIF

        Posté par  (site web personnel) . Évalué à 10.

        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.

        • [^] # Re: Avis sur HEIF

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Cet avis est complÚtement biaisé par un prisme libriste qui fait fi des réalités du marché et des considérations techniques, en gros HEIF c'est le mal parce qu'il y a des brevets dedans, ça me paraßt trÚs court en argumentation.
          Quand les 2 leaders du marché de la photo pro s'y mettent, les pros et les amateurs qui ont les moyens, s'y mettront également par la force des choses.
          Perso je suis utilisateur de reflex Nikon depuis des années et son remplaçant utilisera certainement le format HEIF et je suis heureux de constater que les principaux logiciels de visu/traitement photo reconnaissent ce format (darktable, GIMP, digikam). Qu'aucun navigateur reconnaisse le format, franchement on s'en moque, c'est pas avec un navigateur que je vais visualiser et traiter mes photos.
          Maintenant je ne suis pas sûr que ça soit mon choix pour la conservation de longue durée.

          https://www.funix.org mettez un manchot dans votre PC

          • [^] # Re: Avis sur HEIF

            Posté par  . Évalué à 7.

            Je me trompe peut-ĂȘtre mais j'ai quand mĂȘme l'impression que ceux qui utilisent encore un appareil photo reflex/hybride au lieu ou en plus d'un smartphone sont soit des pros, soit des amateurs passionnĂ©s. Il me semble qu'une proportion non nĂ©gligeable d'entre eux vont dĂ©velopper leurs raw et les exporter dans le format qu'ils veulent, sans se soucier du choix de Canon ou Nikon. Du coup, pas sĂ»r que le format compressĂ© issu du boĂźtier ait un grand impact sur l'Ă©volution du marchĂ©.

            Par ailleurs, je ne visualise pas mes photos avec un navigateur mais j'aime bien en partager certaines avec ma famille oĂč mes amis. Si elles ne sont pas dans un format pris en charge par un navigateur, ça m'oblige Ă  les convertir. Si je dispose d'un format aussi bon (ou meilleur) que HEIF mais pris en charge par les navigateurs, je vais prĂ©fĂ©rer utiliser celui-lĂ  pour mes exports darktable. Et s'il est libre c'est la (grosse) cerise sur le gĂąteau.

            Pour finir, les logiciels que tu cites reconnaissent à peu prÚs tout y compris des formats dont je n'ai jamais entendu parler. Qu'ils sachent visualiser/traiter le HEIF n'indique rien sur la popularité actuelle ou à venir d'un format.

            • [^] # Re: Avis sur HEIF

              Posté par  (site web personnel) . Évalué à 5.

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

            • [^] # Re: Avis sur HEIF

              Posté par  . Évalué à 5.

              Et ceux qui utilisent un smartphone de marque Apple utilisent HEIC car c'est dans ce format que l'iPhone stocke les photos. Donc ĂȘtre capable de lire ce format est important si on veut Ă©viter de dĂ©grader la qualitĂ© (et augmenter la taille des images) en les convertissant en JPEG.

              CECI DIT, si c'est une bonne raison pour que Darktable/Photos/Shotwell/whatever supporte la lecture du foramt HEIC ce n'est pas en soi une raison valable pour utiliser ce format sur le web, car devoir potentiellement payer des royalties est un problĂšme. Dans la mesure oĂč tous les sites "grand public" vont convertir eux-mĂȘme les photos dans un format lĂ©ger quite Ă  ce qu'il soit dĂ©gueulasse, le partage de ces photos n'est pas un argument pertinent pour imposer le support d'un format brevetĂ© dans Firefox ou Chrome.

          • [^] # Re: Avis sur HEIF

            Posté par  (site web personnel) . Évalué à 5.

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

          • [^] # Re: Avis sur HEIF

            Posté par  (site web personnel) . Évalué à 9.

            Cet avis est complÚtement biaisé par un prisme libriste qui fait fi des réalités du marché et des considérations techniques, en gros HEIF c'est le mal parce qu'il y a des brevets dedans, ça me paraßt trÚs court en argumentation.

            Que l'avis soit biaisé par le prisme libriste, je ne m'en défends pas. Que cela veuille dire que ce format va s'implanter ou non, comme je le disais je n'ai pas creusé la question suffisamment pour trancher (et ce n'est malheureusement l'apparente supériorité technique d'un format libre qui assura que ce ne soit pas le cas).

            Par contre je suis surpris de ton argumentation. Tu indiques: "en gros HEIF c'est le mal parce qu'il y a des brevets dedans". Oui, c'est effectivement le mal pour cette raison, indépendamment de considérations techniques. On parle d'un format de fichier, dont le but est le partage d'information. Un format non libre est structurellement nocif pour un libriste. Ce n'est plus réellement interopérable, on est à la merci des propriétaires qui peuvent changer la rÚgle quand ils veulent
 La "guerre des formats pour les documents bureautiques" reste un bon exemple de ce que les brevets sur un format de fichier peut générer.
            J'ai donc tendance à confirmer ta déclaration: HEIF c'est le mal parce qu'il y a des brevets dedans. (j'ai enlevé "en gros").

            • [^] # Re: Avis sur HEIF

              Posté par  (site web personnel, Mastodon) . Évalué à -2.

              Le jour oĂč tu trouveras des APN de qualitĂ© pro avec des formats d'enregistrement libres tu me feras signe. Mais ça tout le monde semble l'ignorer ici par aveuglement idĂ©ologique.

              https://www.funix.org mettez un manchot dans votre PC

              • [^] # Re: Avis sur HEIF

                Posté par  . Évalué à 2. DerniĂšre modification le 28 juin 2023 Ă  08:25.

                Franchement, on s'en fiche du format d'enregistrement des APN de qualité pro, il n'y a aucun aveuglement idéologique là-dedans. Si tu es un pro tu développes tes raw (fermés et non libres, à part le DNG qui est ouvert). Pourquoi faudrait-il promouvoir un format d'image compressé non libre pour un aussi petit marché ? D'ailleurs, le marché ne s'y trompe pas : HEIF n'est pas pris en charge par les navigateurs (et ça sans que Google y mette son grain de sel capricieux).

                Le JPEG-XL a toutes les qualités requises, il est soutenu par de grands acteurs, il est libre de droit et il fonctionne dans les navigateurs (y compris Chrome avant que Google ne le retire). Il ne manque plus que Google qui en est pourtant un des créateurs, revienne sur sa décision et le choix de Nikon ou Sony d'adopter le HEIF ne pÚsera rien du tout dans la balance (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).

                • [^] # Re: Avis sur HEIF

                  Posté par  (site web personnel) . Évalué à 4.

                  (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 ?

                  • [^] # Re: Avis sur HEIF

                    Posté par  . Évalué à 2.

                    Souvent, non, bien sĂ»r. Mais les mises Ă  jour d'APN, ce n'est pas exceptionnel et j'en ai fait deux ou trois moi-mĂȘme.

              • [^] # Re: Avis sur HEIF

                Posté par  (site web personnel) . Évalué à 8. DerniĂšre modification le 28 juin 2023 Ă  09:17.

                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.

                • [^] # Re: Avis sur HEIF

                  Posté par  (site web personnel, Mastodon) . Évalué à 6.

                  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.

                  Je vais pinailler un peu, mais AVIF, c'est aussi du HEIF. C'est d'ailleurs bien Ă©crit dans la dĂ©pĂȘche. HEIF est le nom du conteneur qui est utilisĂ© aussi bien pour AVIF comme pour HEIC.

                  Et donc dans toute votre discussion, en fait, on comprend bien que vous ĂȘtes en train de comparer HEIC et AVIF (et non pas HEIF et AVIF). En gros, ce que tu voulais Ă©crire dans la phrase que j'ai citĂ©e, c'est:

                  Mais à part ça, HEIF HEIC 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.

                  Je n'ai pas les dĂ©tails historiques, mais je suppose que le HEIC est arrivĂ© en premier et comme il Ă©tait donc peut-ĂȘtre le seul Ă  utiliser HEIF, les gens mĂ©langeaient allĂ©grement les genres (d'ailleurs si un fichier a une extension .heif, il me semble que ce sera le plus souvent un .heic en vrai). Ça n'avait pas d'importance alors s'il Ă©tait seul Ă  utiliser ce conteneur. Enfin bon, c'est juste une supposition de ma part.

                  En tous cas, maintenant faut préciser HEIC ou AVIF. Parler de HEIF n'a aucun sens (enfin sauf si on veut vraiment parler du format du conteneur!).

                  Notons que ce pinaillage a son importance: cette confusion semblant un peu rĂ©pandue, certains empaqueteurs de distributions la font aussi, et du coup on a (eu? Je sais pas si c'est encore le cas, Ă  vĂ©rifier
 Par exemple, ce fut le cas chez Fedora qui ont eu du mal Ă  comprendre que HEIF ≠ HEIC et que les problĂšmes lĂ©gaux Ă©taient avec HEIC — le codage HEVC/H.265 plus particuliĂšrement — mais il semblerait qu'ils aient finalement compris puisque je vois qu'il y a finalement un paquet depuis mi-mars qui intĂšgre maintenant bien la prise en charge de AVIF mais pas de HEIC) des problĂšmes car les distributions qui font attention aux brevets logiciels n'intĂ©graient pas la bibliothĂšque libheif et dĂ©sactivaient entiĂšrement notre plug-in file-heif dans GIMP, dĂ©sactivant ainsi aussi bien la prise en charge de HEIC que de AVIF. C'est ballot si on veut promouvoir la variante ouverte et sans brevet (AVIF donc) utilisant du HEIF!

                  Alors qu'il suffit d'avoir un paquet libheif qui ne contienne que les codecs de compression et décompression pour AVIF (puisque cette bibliothÚque est aussi modulaire). Notre plug-in file-heif faisant aussi une vérification à l'exécution, GIMP ne proposera alors que AVIF.

                  C'est d'autant plus sympa qu'il suffit qu'un projet de dĂ©pĂŽt tiers qui s'en foute des brevets (tels que RPMFusion ou encore notre bon vieux Penguin Liberation Front, qui malheureusement n'existe plus, mĂȘme s'il avait un nom et un logo assez marrants! 😜) fasse un paquet contenant simplement les codecs supplĂ©mentaires pour que GIMP ait magiquement la prise en charge de HEIC au redĂ©marrage (avec le mĂȘme paquet pour GIMP).

                  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                  • [^] # Re: Avis sur HEIF

                    Posté par  (site web personnel) . Évalué à 2.

                    projet de dépÎt tiers qui s'en foute des brevets (tels que RPMFusion ou encore notre bon vieux Penguin Liberation Front

                    euh, ils ne se foutent pas des brevets : ils prennent en compte le fait que les brevets logiciels sont (encore longtemps j'espÚre) illégaux au moins en Europe :-)

                    c'est pour cela que chez Mageia, tu trouves un paquet libheif dans core (n'incluant pas ce qui est potentiellement couvert par des brevets logiciel) et un autre dans tainted (qui intĂšgre — notamment — ce dont les brevets logiciels ne peuvent te priver) : l'idĂ©e est de faciliter le travail des miroirs/distributeurs de paquets — selon le pays qui les hĂ©berge — pour respecter la loi locale.

                    cf. définition du contenu des dépÎts Mageia : core / nonfree et tainted (avec les updates correspondants)

                    • [^] # Re: Avis sur HEIF

                      Posté par  (site web personnel, Mastodon) . Évalué à 3.

                      projet de dépÎt tiers qui s'en foute des brevets (tels que RPMFusion ou encore notre bon vieux Penguin Liberation Front

                      euh, ils ne se foutent pas des brevets : ils prennent en compte le fait que les brevets logiciels sont (encore longtemps j'espÚre) illégaux au moins en Europe :-)

                      Au cas oĂč ce n'Ă©tait pas clair, ce n'Ă©tait pas une critique nĂ©gative sur ces projets, bien au contraire.

                      Moi aussi je me fous de plein de trucs. Je pense ne pas ĂȘtre un mauvais bougre pour autant. Enfin j'espĂšre
 😅

                      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: Avis sur HEIF

                Posté par  (site web personnel) . Évalué à 4.

                Il me semble que tu confondes diffusion d’un format, qualitĂ© intrinsec du format et sa diffusion.

                .doc était trÚs largement diffusé, remplissait sa fonction, mais posait néanmoins de gros problÚmes.

                HEIF n’est pas largement diffusĂ©, remplit probablement ça fonction, mais pose nĂ©anmoins de gros problĂšmes. C’est donc un format qui n’est pas souhaitable, mĂȘme si, comme je l’ai dit plusieurs fois, ça ne veut pas dire qu’il ne sera pas diffusĂ©.

                Ce n’est pas parce que les appareils utilisant un meilleur format n’existent pas (je te crois lĂ  dessus, je n’ai pas vĂ©rifiĂ©) que ce n’est pas un problĂšme et qu’il faille en dĂ©duire que le format est bien.

                Si tu veux nous convaincre qu’il est bien, montre nous en quoi il est techniquement supĂ©rieur aux autres prĂ©sentĂ©s, et en quoi ces avantages sont tellement majeur qu’ils justifient les contraintes qu’il apporte.

                C’était le sujet de la question, alors que tu sembles t’accrocher Ă  la diffusion.

          • [^] # Re: Avis sur HEIF

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            les pros et les amateurs qui ont les moyens

            Ca, c'est 1% du marché. 80%, c'est le web et le web n'a pas envie de payer des licences. Le web, ce sont les navigateurs mais aussi les sites web qui te demandent d'importer une photo.

            Au final si l'open-source s'est imposé presque partout dans l'informatique, il y a une raison: il pose moins de problÚmes.

            Et puis, ce n'est pas pour te déprimer mais il n'y a plus grand monde à avoir un appareil photo (Nokia ou autre). Alors Apple fera toujours sa sauce mais cela reste entre gens Apple.

            Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

            • [^] # Re: Avis sur HEIF

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Ca, c'est 1% du marché. 80%, c'est le web et le web n'a pas envie de payer des licences. Le web, ce sont les navigateurs mais aussi les sites web qui te demandent d'importer une photo.

              je suis dans les 1% qui investissent dans des boitiers et téléobjectifs pour faire de la photo animaliÚre et sportive et j'espÚre bien que mon systÚme gnu/linux continuera à prendre en compte tous les formats y compris les plus privatifs que les grands constructeurs comme Canon et Nikon choisiront.

              https://www.funix.org mettez un manchot dans votre PC

              • [^] # Re: Avis sur HEIF

                Posté par  (site web personnel) . Évalué à 6. DerniĂšre modification le 25 juillet 2023 Ă  16:34.

                Et ça ne te dirait pas d'espérer que les grands constructeurs comme Canon et Nikon choisiront des formats ouverts ? Voire carrément de leur demander, d'ailleurs ?

                Et de toute façon, subir un format, c'est une chose, mais en choisir un pour stocker les images qu'on produit soi-mĂȘme, par exemple avec une retouche ou une crĂ©ation numĂ©rique, c'en est une autre.

                HEIC est un format de niche, qui ne s'imposera pas sur Internet. La place est déjà prise par JPEG, WebM, AVIF et bientÎt JPEG-XL. Si tu produis des images, les enregistrer en HEIC est un trÚs mauvais choix.

                • [^] # Re: Avis sur HEIF

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Et ça ne te dirait pas d'espérer que les grands constructeurs comme Canon et Nikon choisiront des formats ouverts ? Voire carrément de leur demander, d'ailleurs ?

                  j'ai passé l'ùge d'écrire des lettres au pÚre noël, j'y crois plus

                  HEIC est un format de niche, qui ne s'imposera pas sur Internet. La place est déjà prise par JPEG, WebM, AVIF et bientÎt JPEG-XL. Si tu produis des images, les enregistrer en HEIC est un trÚs mauvais choix.

                  je suis d'accord, ça ne sera certainement pas mon choix pour la conservation de mes images, je continuerai à opter pour un format le plus ouvert possible

                  https://www.funix.org mettez un manchot dans votre PC

                • [^] # Re: Avis sur HEIF

                  Posté par  . Évalué à 0. DerniĂšre modification le 26 juillet 2023 Ă  21:52.

                  Si tu produis des images, les enregistrer en HEIC est un trĂšs mauvais choix.

                  Personnellement, je n'ai toujours pas compris l'engouement général pour des formats destructifs. Que des gens bousillent leur boulot en toute connaissance de cause me sidÚre. C'est un peu comme si des musiciens enregistraient en studio en mp3 !

                  • [^] # Re: Avis sur HEIF

                    Posté par  . Évalué à 5.

                    Personnellement, je n'ai toujours pas compris l'engouement général pour des formats destructifs. Que des gens bousillent leur boulot en toute connaissance de cause me sidÚre. C'est un peu comme si des musiciens enregistraient en studio en mp3 !

                    Ta comparaison ne s'applique pas Ă  la photo. MĂȘme en choisissant un format non compressĂ©, on perd de l'information si on ne garde pas le raw d'origine. Il sera par exemple trĂšs difficile de corriger une balance des blancs Ă  partir de la photo produite mĂȘme si elle est enregistrĂ©e dans un format non compressĂ©. Je pense que la majoritĂ© des pros et sans doute beaucoup d'amateurs passionnĂ©s, gardent les raw en plus des photos produites.

                    Ensuite, le choix d'enregistrer la photo dans un format destructif, qu'il soit fait dans l'appareil photo, le smartphone ou sur le PC par quelqu'un qui dĂ©veloppe ses raw, est plus le rĂ©sultat d'un compromis que celui d'un engouement vu qu'il peut facilement y avoir un rapport de 1 Ă  10 en taille pour une diffĂ©rence difficilement visible dans le cas d'utilisation le plus courant : l'affichage sur un Ă©cran. Ceci n'empĂȘche pas de produire une nouvelle version de la photo dans un format non destructif si le besoin s'en fait sentir, en repartant du raw.

                    NB. Tous les appareils photo (autres que les entrĂ©es de gamme qui de toutes façons disparaissent au profit des smartphones) permettent de garder les raw des photos prises. Et mĂȘme certains smartphones.

                    • [^] # Re: Avis sur HEIF

                      Posté par  (site web personnel, Mastodon) . Évalué à 3.

                      Pour complĂ©ter la comparaison : les fichiers raw ne sont pas des fichiers image. C’est un enregistrement des donnĂ©es sorties du capteur, non modifiĂ©es1. Il faut un traitement complexe plein de choix arbitraires pour transformer un raw en image.

                      Pour garder le parallĂšle musical, les raw c’est les fichiers master de la photo, les donnĂ©es brutes d’enregistrement sur lesquelles tu ne veux aucune compression destructive, mais qui ne servent Ă  rien en soi, sans traitement.

                      Beaucoup de gens n’ont ni besoin ni utilitĂ© de ces donnĂ©es, ce qu’ils veulent, c’est juste le rĂ©sultat final, prĂȘt Ă  l’emploi. Ça implique d’accepter les choix arbitraires susmentionnĂ©s qu’a fait l’appareil (smartphone ou « JPEG/HEIF du boiter ») sans retraitement ailleurs qu’à la marge, et trĂšs souvent ça fait le boulot. Ces fichiers pourraient ĂȘtre produits sans compression destructive (mais pas sans destruction, les donnĂ©es du capteurs ne pouvant pas ĂȘtre retrouvĂ©es suite aux traitements effectuĂ©s pour les transformer en image), mais ça n’a pas grand intĂ©rĂȘt.


                      1. Deux exceptions connues : 1. Toute la profondeur de donnĂ©es peut ne pas ĂȘtre enregistrĂ©e (raws sur 12 bits mais capteur sur 14) ; 2. Certains boitiers intĂšgrent une correction du bruit thermique dans les donnĂ©es raw sur les poses longues. ↩

                      La connaissance libre : https://zestedesavoir.com

                  • [^] # Re: Avis sur HEIF

                    Posté par  (site web personnel) . Évalué à 3.

                    Ça dĂ©pend du prix que tu veux mettre dans une carte SD gĂ©ante, et dans le disque dur oĂč tu dĂ©charges tes photos en fait.

                    • [^] # Re: Avis sur HEIF

                      Posté par  . Évalué à 1. DerniĂšre modification le 27 juillet 2023 Ă  10:15.

                      Cela dépend surtout du fait que beaucoup de gens ne trient pas, ils conservent des milliers de photos inutiles, parfois des dizaines ou centaines de milliers. Ainsi va le numérique, la quantité au détriment de la qualité. Perso, je bosse avec la photo, je ne travaille pas avec du destructif, je trie, je jette et je ne possÚde pas de stockage géant.

                      • [^] # Re: Avis sur HEIF

                        Posté par  (site web personnel, Mastodon) . Évalué à 3. DerniĂšre modification le 27 juillet 2023 Ă  10:35.

                        Il faut aussi vachement relativiser la notion de « stockage gĂ©ant » pour de la photo, on est trĂšs loin des volumes nĂ©cessaires pour la vidĂ©o. Aujourd’hui, un appareil photo haut de gamme capteur plein format peut avoir un capteur de 45 Mpx, et gĂ©nĂ©rera des raw de 50 Mo environ.

                        Si tu prends 20 000 photos par an (ce qui est Ă©norme, ça fait plus de 50 par jours, tous les jours), et que tu conserves tout, ça ne fait que 1 To, ce qui tient sans aucun problĂšme sur n’importe quel systĂšme de stockage de masse.

                        Les photos JPEG/HEIF sont plus petites d’un ordre de grandeur (5 Mo environ piĂšce), mĂȘme un photographe compulsif qui conserve absolument tout peut tout garder sans problĂšme.

                        PS : d’autre part, quand j’ai retraitĂ© mes photos du Japon, j’étais trĂšs content d’avoir gardĂ© tous les raw, ça m’a permis de refaire ces traitements propres.

                        La connaissance libre : https://zestedesavoir.com

  • # Titre de la dĂ©pĂȘche ambigu

    Posté par  (site web personnel) . Évalué à 6.

    Merci pour cette dĂ©pĂȘche trĂšs intĂ©ressante et trĂšs instructive.
    Par contre dans son titre j'aurai bien précisé "Des formats d'images pour le Web", ou pour élargir un peu les usages "Des formats d'images à l'Úre Web".
    En effet, ayant personnellement commencé l'informatique à l'ùge de la cassette puis à l'ùge de la disquette, les premiers formats d'images que j'ai pu utiliser étaient plutÎt Tiff, TGA, PCX et BMP (et j'en oublie sans doute
), avant l'arrivée du Gif.
    Mon "prĂ©fĂ©rĂ©" Ă©tait le TGA car au moins on pouvait avoir des images en
 256 couleurs (wahou !
) !

  • # Merci

    Posté par  . Évalué à 3.

    Beaucoup,

    TrÚs intéressante mise à niveau


    ++

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

  • # Compression sans perte ou encodage ?

    Posté par  (site web personnel) . Évalué à 1.

    Pour moi, le bit étant par nature incompressible, le terme « compression » sous-entend nécessairement perte d'information.

    Quand il n'y a pas de perte d'information, il s'agit d'une façon différente d'organiser les bits qui aboutit à réduire l'occupation mémoire, alors je pense que le terme « encodage » serait plus approprié.

    Me trompé-je ?

    « J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »

    • [^] # Re: Compression sans perte ou encodage ?

      Posté par  . Évalué à 7.

      Le bit est incompressible, mais on ne compresse jamais un bit, mais une séquence de bits.

      La compression de donnĂ©es ou codage de source est l'opĂ©ration informatique consistant Ă  transformer une suite de bits A en une suite de bits B plus courte pouvant restituer les mĂȘmes informations

      (wp, je sais pas d’ou vient le terme "codage de source")

      Par analogie avec la compression de gaz, on garde bien toutes les molécules de gaz mais dans un espace plus étroit.

      • [^] # Re: Compression sans perte ou encodage ?

        Posté par  (site web personnel, Mastodon) . Évalué à 7.

        Le codage de source vient des tĂ©lĂ©communications oĂč on a souvent une chaĂźne de traitement comportant un codage de source (consistant Ă  encoder les donnĂ©es efficacement pour supprimer la redondance, c'est Ă  dire, compresser), suivi d'un codage de canal, consistant lui Ă  rajouter de la redondance, mais prĂ©dictible cette fois-ci (contrĂŽle d'erreur, paritĂ©, CRC, 
) afin que le rĂ©cepteur puisse en tirer parti pour corriger les erreurs qui surviendront pendant la transmission du message.

      • [^] # Re: Compression sans perte ou encodage ?

        Posté par  . Évalué à 1.

        Le bit est incompressible

        Ouais, sauf en informatique quantique. Et dans certains films aussi.

    • [^] # Re: Compression sans perte ou encodage ?

      Posté par  . Évalué à 5. DerniĂšre modification le 26 juin 2023 Ă  11:07.

      Les formats habituels de compression de données (gzip, bzip, lzma, etc) sont heureusement sans perte. On parle de compression parce que la taille finale est inférieure à la taille initiale, le fait que cela passe par un encodage de Huffman ou équivalent est un détail d'implémentation.

    • [^] # Re: Compression sans perte ou encodage ?

      Posté par  . Évalué à 3. DerniĂšre modification le 26 juin 2023 Ă  12:15.

      Quand je compresse un dossier en zip je ne perds pas de données.

      edit: désolé je n'avais pas vu le message au dessus de nud

  • # PNG encore utile.

    Posté par  (Mastodon) . Évalué à 8.

    En PNG tu n'as pas obligatoirement :

    en niveau de gris sur 8 bits ou en RVB sur 24 bits, avec une transparence optionnelle par canal alpha sur 8 bits.

    Tu peux utiliser une palette et choisir le nombre de couleurs.
    Donc pour un logo avec genre trois couleurs, ben tu fais une palette à
 trois couleurs, et l'image qui sort est trùs trùs petite, et toujours autant sans perte et lisible partout.
    En pratique il semble utiliser des palettes 2-bits/4-bits/8/16/32, etc. Donc on n'optimise pas non plus à mieux qu'une puissance de 2, mais c'est déjà sacrément efficace.

    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.

    En tout cas, une favicon de site web bien faite devrait ĂȘtre en PNG Ă  micro-palette.
    Tu peux avoir une icĂŽne en 256x256 Ă  moins de 3ko.

    Bref, c'est du détail, mais j'ai pas encore trouvé mieux pour cet usage spécifique, que j'utilise beaucoup en icÎne de répertoires, ou en favicon de site web.

    • Yth.
    • [^] # Re: PNG encore utile.

      Posté par  (Mastodon) . Évalué à 3.

      Ya mĂȘme la palette 1-bit pour une icĂŽne en ombre chinoise : noir et transparent, j'ai un exemple en 171x171 qui fait 549 octets, imbattable ?

      • Yth.
    • [^] # Re: PNG encore utile.

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Pourquoi pas un svg pour les logos, favicon et icÎnes ? C'est tout à fait adapté pour ce type d'images et encore plus léger.

      « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

      • [^] # Re: PNG encore utile.

        Posté par  (site web personnel) . Évalué à 5. DerniĂšre modification le 26 juin 2023 Ă  10:39.

        Sur des images trĂšs petites je ne pense pas que le vectoriel soit pertinent. Il faut le convertir en pixels avant de l'afficher, et avec les filtres antialiasing ça ajoute du flou. Sans antialiasing on a des pixels qui peuvent ne pas ĂȘtre au bon endroit et qui font tache.

        Avec une petite icÎne matricielle on peut faire du pixel art et avoir des images trÚs lisibles malgré le faible nombre de pixels.

        Un LUG en Lorraine : https://enunclic-cappel.fr

        • [^] # Re: PNG encore utile.

          Posté par  . Évalué à 4.

          D'ailleurs, on a souvent le combo : SVG pour le logo en grand, puis les versions matricielles pour les formats de 8x8 jusqu'Ă  32x32 voire plus.

      • [^] # Re: PNG encore utile.

        Posté par  (site web personnel) . Évalué à 6.

        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.

        • [^] # Re: PNG encore utile.

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Ah oui, effectivement, je viens de faire un test sur une icÎne que j'ai dessinée :

          • svg Inkscape : 5,1 Kio
          • png 96 ppp exportĂ© dans Inkscape : 1,3 Kio.

          Dans un dossier oĂč j'ai deux version SVG/PNG de mes icĂŽnes, le rapport peut mĂȘme ĂȘtre plus important (de 12,4 Kio, svg, Ă  2 Kio, png, voire 5,1 kio pour le svg et 464 octets pour la version png).

          « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

          • [^] # Re: PNG encore utile.

            Posté par  (site web personnel) . Évalué à 2.

            Et aprÚs compression du SVG par gzip -9, ou zopfli ? Ou brotli. Le SVG se compresse trÚs bien.

          • [^] # Re: PNG encore utile.

            Posté par  (site web personnel) . Évalué à 4.

            Autre chose, l'export SVG Inkscape garde pas mal d'infos inutiles pour l'affichage (mais utile pour l'édition), il faut choisir l'option "SVG Optimisé" dans l'enregistrer sous (et ensuite il y a plein de paramÚtres sur lesquels on peut jouer pour réduire la taille).

      • [^] # Re: PNG encore utile.

        Posté par  . Évalué à 2.

        Pas sĂ»r que ce soit aussi lĂ©ger sur une image aux formes complexes. Et puis quid du rendu SVG par le navigateur ? ça bouffe des ressources quand mĂȘme.

        • [^] # Re: PNG encore utile.

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          On parle d'icÎne, de favicon et de logos là, pas d'images complexes (sinon c'est le logo ou les icÎnes ne sont pas adaptés).

          « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

    • [^] # Re: PNG encore utile.

      Posté par  (site web personnel) . Évalué à 3.

      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.

    • [^] # Re: PNG encore utile.

      Posté par  . Évalué à 3. DerniĂšre modification le 26 juin 2023 Ă  11:08.

      En Gif tu peux indiquer le nombre de couleurs que tu veux. S'il n'y a pas de transparence, et avec un peu d'astuces pour forcer le choix des couleurs, c'est encore plus léger.

      • [^] # Re: PNG encore utile.

        Posté par  (site web personnel) . Évalué à 5. DerniĂšre modification le 26 juin 2023 Ă  11:18.

        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.
        • [^] # Re: PNG encore utile.

          Posté par  . Évalué à 3. DerniĂšre modification le 26 juin 2023 Ă  23:30.

          Dans la mesure oĂč un une icĂŽne de 16×16 contient 256 pixels, Ă  raison de 32 bits par pixel (soit 3 canaux couleurs de 8 bits + un canal de transparence) on obtient 1024 octets, ou 1 kio, soit le "PNG optimisĂ©" ne l'est pas du tout, soit il stocke masse de mĂ©tadonnĂ©es.

          Si ton image est en noir et transparent (soit deux couleurs) elle peut théoriquement tenir sur 256 bits, soit 32 octets, sans compression, à quoi il faut ajouter la taille de la palette de deux couleurs.

          Avec gimp et les directives que tu donnes j'obtiens une image de 143 bytes, dont, si je n'ai pas fait d'erreur:

          • une palette (section PLTE) de 6 octets
          • un masque (section tRNS) de 1 octet
          • une section de donnĂ©es (IDAT) de 55 octets

          Au final il y a plus d'octets liĂ©s au format lui-mĂȘme (rien que le bornage et l'identification des 5 sections ça fait 60 octets) que de donnĂ©es


          Le hexdump pour les curieux, qui est plus court que le commentaire:

          00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
          00000010  00 00 00 10 00 00 00 10  01 03 00 00 00 25 3d 6d  |.............%=m|
          00000020  22 00 00 00 06 50 4c 54  45 dc ba 55 00 00 00 66  |"....PLTE..U...f|
          00000030  3f 8a be 00 00 00 01 74  52 4e 53 00 40 e6 d8 66  |?......tRNS.@..f|
          00000040  00 00 00 37 49 44 41 54  08 d7 63 60 64 60 00 22  |...7IDAT..c`d`."|
          00000050  26 06 86 26 06 06 27 76  06 25 2b 06 d1 23 0c 7c  |&..&..'v.%+..#.||
          00000060  1c 0c 36 02 0c c7 14 18  38 0f 30 70 34 30 70 3a  |..6.....8.0p40p:|
          00000070  30 70 29 30 f0 08 30 48  70 00 00 74 54 05 4d 1c  |0p)0..0Hp..tT.M.|
          00000080  d8 80 79 00 00 00 00 49  45 4e 44 ae 42 60 82     |..y....IEND.B`.|
          0000008f
          
          • [^] # Re: PNG encore utile.

            Posté par  (site web personnel) . Évalué à 3.

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

            • [^] # Re: PNG encore utile.

              Posté par  (site web personnel) . Évalué à 5.

              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.

              • [^] # Re: PNG encore utile.

                Posté par  . Évalué à 5.

                Je pense que pour un si petit fichier ce genre de pinaillage n'a aucun intĂ©rĂȘt pratique. Sur le disque un fichier va occuper au minimum un bloc de 4 kB sur un disque formattĂ© en ext4 donc toute taille de fichier infĂ©rieure n'a aucune pertinence. En HTTP il est plus difficile de juger mais avec la masse de donnĂ©es envoyĂ©e en en-tĂȘtes, certificats TLS, etc., on n'est sans doute pas Ă  un ou deux kB prĂšs non plus.

                La seule chose que ça démontre c'est que certains formats ont une structure plus lourde que d'autres, typiquement liée à la flexibilité dudit format. Il serait plus intéressant de comparer de "grosses" images de différents types et c'est pour ça que c'est ce que les benchmarks font.

                • [^] # Re: PNG encore utile.

                  Posté par  (Mastodon) . Évalué à 2.

                  Les trop petits fichiers, en effet, on voit l'overhead de la structure, et donc on compare mal.
                  Certes, je parle ici de petits fichiers, donc la structure n'est pas nĂ©gligeable non plus, mais peut-ĂȘtre pas si petit, plutĂŽt du 128x128 ou 256x256 avec quelques couleurs, 8 Ă  32 en gĂ©nĂ©ral.

                  Et donc j'ai pris une série d'icÎnes comme ça que j'avais sous la main, je me suis assurés qu'elles soient bien passées à travers un optipng ou pngquant (j'utilise trimage qui fait ça tout seul).
                  Et puis aprùs un convert de masse vers gif, jpg, webp, avif

                  Bilan, y'en avait pour 900ko en PNG, on passe à 700ko en webp, on monte à 1500 en gif et avif, et à presque 2Mo en jpg (mais on pourrait réduire la qualité et donc la taille, il faudrait analyser image par image pour savoir si la qualité est encore correcte).

                  Donc apparemment webp l'emporte au final.
                  Sauf que mon navigateur de fichier ne lit pas le webp pour les icÎnes, et que mes répertoires n'ont plus d'icÎnes si je met du webp, mais c'est un détail du présent, pas du futur.

                  Ce qui est assez fun, c'est que l'icÎne que j'ai utilisé pour tester si mon navigateur de fichier lisait le webp est une image de 256x256 en 1-bit : noir et transparence, et que les fichiers PNG et webp font tout deux exactement 810 octets.

                  • Yth.
                  • [^] # Re: PNG encore utile.

                    Posté par  (site web personnel) . Évalué à 6.

                    Allez, Ă  mon tour.

                    Compression de 44 icînes en 64×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×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).

                    • [^] # Re: PNG encore utile.

                      Posté par  (site web personnel) . Évalué à 6.

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

                  • [^] # Re: PNG encore utile.

                    Posté par  (site web personnel) . Évalué à 3.

                    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.

                    • [^] # Re: PNG encore utile.

                      Posté par  (Mastodon) . Évalué à 4.

                      On est d'accord, c'est une sorte de rĂ©fĂ©rence, juste pour montrer que le format adaptĂ©, mĂȘme si on pinaille entre png ou webp, c'est dĂ©jĂ  le bon premier choix Ă  faire.

                      • Yth.
              • [^] # Re: PNG encore utile.

                Posté par  (site web personnel, Mastodon) . Évalué à 4.

                Je ne sais pas comment ce SVG est optimisé, mais par exemple, le logo de Google tient dans un SVG de 305 octets, et en passant un peu de temps sur le sujet, des gens sont arrivés à le réduire à 146 octets:

                https://clicktorelease.com/blog/svg-google-logo-in-305-bytes/

                Et ça c'est pour le SVG. Comme ce n'est pas toujours suffisant, il existe des formats vectoriels conçus pour prendre trÚs peu de place. Le format HVIF de Haiku est un exemple, et il y a aussi IconVG. Mais pour l'instant, pas d'utilisation possible dans les navigateurs web :(

              • [^] # Re: PNG encore utile.

                Posté par  . Évalué à 2.

  • # Et la compression fractale ?

    Posté par  . Évalué à 3.

    Dans la premiĂšre moitiĂ© des annĂ©es 90, je me souviens m'ĂȘtre amusĂ© avec des logiciels de compression fractale. J'Ă©tais persuadĂ© que c'Ă©tait des fichiers JFIF, mais d'aprĂšs https://en.wikipedia.org/wiki/Comparison_of_graphics_file_formats, JFIF est juste un format conteneur.

    Il me semble que la compression était terriblement longue (jusqu'à une heure sur mon 486DX pour des images 640x480 - ce qu'on appelait de la haute résolution à l'époque !). Mais la taille du fichier résultat était ridicule - je ne sais pas comment ça se comparerait avec du WebP aujourd'hui. La décompression était également assez lente.

    Le cÎté rigolo, c'est qu'on pouvait zoomer à l'infini, y'avait pas de pixelisation. A la place, l'algo "imaginait" l'image.

    J'ai cherché fractal compression sur Wikipedia, mais je tombe sur rien que je reconnaisse. Y'aurait pas un autre fossile dans les parages qui pourrait m'éclairer ?

  • # Et le format BPG

    Posté par  (site web personnel) . Évalué à 4.

    J'ai dĂ©couvert via le commentaire, il y a 2 ans sur : https://linuxfr.org/news/ffmpeg-1-0#comment-1395216 l'existence du format BPG de Fabrice Bellard avec la dĂ©mo accessible sur son site : https://bellard.org/bpg/, dĂ©mos que je trouve convaincantes
 mais ce n'est malheureusement pas toujours les meilleurs projets qui sont diffusĂ©s !

    • [^] # Re: Et le format BPG

      Posté par  . Évalué à 5.

      BPG a Ă©tĂ© rendu obsolĂšte par FLIF, lui mĂȘme rendu obsolĂšte par JPEGXL

  • # Formats non destructifs indispensables

    Posté par  . Évalué à 2.

    Conserver l'intĂ©gralitĂ© de l'image numĂ©rique est une prioritĂ© quand on travaille dans l'Art, d'oĂč l'existence des formats non destructifs tiff et xcf
    Concernant ImageMagick, il ne gĂšre que les .xcf 8-bit. Les .xcf 16-bit et 16-bit float ne sont pas pris en charge. MĂȘme problĂšme concernant KImageFormats exposĂ© ici et GraphicsMagick

    • [^] # Re: Formats non destructifs indispensables

      Posté par  (site web personnel) . Évalué à 4.

      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.

      • [^] # Re: Formats non destructifs indispensables

        Posté par  . Évalué à 1.

        stockage interopérable de travaux graphiques : OpenRaster

        Selon mon expérience, trÚs mauvaise idée. Ensuite, chacun est libre


      • [^] # Re: Formats non destructifs indispensables

        Posté par  (Mastodon) . Évalué à 4.

        Pour TIFF, c'est compliqué.

        J'aimerais bien que tu en dises plus sur cette « complication » 

        • [^] # Re: Formats non destructifs indispensables

          Posté par  . Évalué à 7.

          TIFF, c'est un format conteneur (un peu comme ogg en audio ou mkv en vidĂ©o) qui peut contenir Ă  peu prĂšs n'importe quoi. Fun fact, le TIFF peut ĂȘtre destructif si l'image est stockĂ©e JPEG dans le conteneur.

          D'ailleurs une expansion non-officielle de TIFF c'est Thousands of Incompatible File Formats


        • [^] # Re: Formats non destructifs indispensables

          Posté par  . Évalué à 2.

          Dans un TIFF, voici les méthodes de compression que je peux employer :
          - JPEG
          - LZW
          - PACKBITS
          - DEFLATE
          - CCITTRLE
          - CCITTFAX3
          - CCITTFAX4
          - LZMA
          - ZSTD
          - LERC
          - LERC_DEFLATE
          - LERC_ZSTD
          - WEBP
          - JEPG-XL

          Chacune de ces mĂ©thodes a ses paramĂštres propres qui seront a adapter selon le type de donnĂ©es (image monobande 1bit, 4 bandes, avec ou sans pertes, etc.). Cela la comparaison compliquĂ©e vu que pour un mĂȘme Ă©chantillon, on peut obtenir plĂ©thore de rĂ©sultats :)

          • [^] # Re: Formats non destructifs indispensables

            Posté par  . Évalué à 3.

            Question naĂŻve : certains de ces formats incluent des champs pour les mĂ©tadonnĂ©es ; du coup, quel est l'intĂ©rĂȘt de les encapsuler dans du TIFF ?

            • [^] # Re: Formats non destructifs indispensables

              Posté par  . Évalué à 4.

              L'accĂšs a une plĂątrĂ©e d'options non disponible dans un seul format ou compression ? Par exemple, le tiff permettait de dĂ©passer une limite de 4Gb, de tuiler pour dĂ©passer des dimensions de 100000x1000000, etc. MĂȘme si la spĂ©cification de la compression employĂ©e ne le permet pas.

              Ça reste le format de conteneur le plus mal employĂ© mais qui, maĂźtrisĂ©, rĂ©pond Ă  la plus large gamme de besoins.

              • [^] # Re: Formats non destructifs indispensables

                Posté par  . Évalué à 2.

                Il ne faut pas oublier que TIFF signifie "Thousands of Incompatible File Format" :-)
                Plus sérieusement, c'est «Tag Image File Format» mais sa «plùtrée d'options» n'a probablemnt pas aidé à faire accepter le format auprÚs du grand public. Entre les tags baseline, les tags d'extension et les tags propriétaires, c'est un peu la jungle non?

                Dans le mĂȘme genre mais encore plus spĂ©cialisĂ©, il y a FITS «Flexible Image Transport System», un format d'image trĂšs utilisĂ© en astronomie. Il permet de stocker des informations trĂšs diverses comme des spectres lumineux ou des images non RBG (infrarouge, rayons-X, 
)

    • [^] # Re: Formats non destructifs indispensables

      Posté par  (site web personnel) . Évalué à 7.

      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. :-)

      • [^] # Re: Formats non destructifs indispensables

        Posté par  . Évalué à 1.

        dans l'art, sans majuscule

        J'aurais pu préciser "Arts plastiques"

        • [^] # Re: Formats non destructifs indispensables

          Posté par  (site web personnel) . Évalué à 9. DerniĂšre modification le 26 juin 2023 Ă  17:41.

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

          • [^] # Re: Formats non destructifs indispensables

            Posté par  . Évalué à -2.

            L'Art, celui que font les artistes depuis la nuit des temps, s'est toujours Ă©crit avec un grand "A". Pour rĂ©sumer, il y a art et Art. J'ai pratiquĂ© et pratique les deux, la dĂ©marche n'a rien Ă  voir, mĂȘme si les outils sont parfois les mĂȘmes.

            • [^] # Re: Formats non destructifs indispensables

              Posté par  . Évalué à 3.

              Et, par curiosité intéressée, tu fais quoi ?

              • [^] # Re: Formats non destructifs indispensables

                Posté par  . Évalué à 1.

                En essayant de rĂ©sumer: je crĂ©e des Ɠuvres que l'on pourrait appeler "expĂ©rimentales" en mĂ©langeant plusieurs techniques, photo, numĂ©rique, argentique, vidĂ©o et peinture. Je tiens au cotĂ© expĂ©rimental pour rester libre de casser ce qui me semble bon de casser, sans le souci de la rentabilitĂ©.

            • [^] # Re: Formats non destructifs indispensables

              Posté par  (site web personnel, Mastodon) . Évalué à 8.

              L'Art, celui que font les artistes depuis la nuit des temps, s'est toujours Ă©crit avec un grand "A".

              Il faudrait des rĂ©fĂ©rences lĂ . Parce que c’est la premiĂšre fois que je vois cette « rĂšgle ». MĂȘme l'AcadĂ©mie française n’est pas d’accord.

              (Parfois avec une majuscule.) ActivitĂ© dĂ©sintĂ©ressĂ©e qui a son but et sa fin en elle-mĂȘme, selon un idĂ©al esthĂ©tique.

              Parfois, pas toujours.

              Le CNRTL ne mentionne pas cette soi-disant impĂ©rative capitale sauf dans Beaux-Arts. Pas de majuscule non plus dans WikipĂ©dia, ni dans le Wiktionnaire, ni dans le Larousse, ni dans le LittrĂ©. Et mĂȘme dans un cet article, Ă  la typographie soignĂ©e, sur l'art dans la philosophie, toujours pas de capitale Ă  l’initiale.

              « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

              • [^] # Re: Formats non destructifs indispensables

                Posté par  . Évalué à -1. DerniĂšre modification le 27 juin 2023 Ă  11:55.

                La rĂ©ponse est dans ton lien de l'AcadĂ©mie française, et pour moi, le seul "art" qui mĂ©rite d'ĂȘtre appelĂ© Art est celui-ci:

                "L’Art pour l’Art, attitude de crĂ©ateurs Ɠuvrant sans prĂ©occupation morale ou utilitaire"

                J'admets que tout ceci est subjectif et prĂȘte le flanc Ă  la critique: Ă©litisme, sectarisme, etc
 J'assume.

              • [^] # Re: Formats non destructifs indispensables

                Posté par  (site web personnel, Mastodon) . Évalué à 4.

                Un apartĂ© sur les dictionnaires : l’acadĂ©mie française n’a aucune lĂ©gitimitĂ© rĂ©elle et son dictionnaire est complĂštement obsolĂšte. Le TrĂ©sor de la Langue Française (qui est la premiĂšre entrĂ©e par dĂ©faut du CNRTL) est lui terminĂ© depuis 1994 (presque 30 ans) et n’a pas vocation Ă  ĂȘtre mis Ă  jour. Le Wiktionnaire est un bon dictionnaire d’usage (c’est-Ă -dire qu’il va rĂ©fĂ©rencer les usages passĂ©s mais aussi trĂšs rĂ©cents et rares) des mots, contrairement au Larousse, Robert ou LittrĂ© qui attendent un usage plus « acadĂ©mique » ou journalistique avant d’accepter des mots.

                À ce sujet, le fait qu’un mot soit utilisĂ© dans un sens qui n’est pas rĂ©fĂ©rencĂ© par le Wiktionnaire est un signal fort que l’usage est ultra-restreint. Par exemple, ce dictionnaire renseigne « fora » au sens de pluriel de « forum », qui est une forme qu’à peu prĂšs personne n’utilise et qui n’est rĂ©fĂ©rencĂ© que par une vieille Ă©dition d’un Larousse en-dehors de ce dictionnaire.

                La connaissance libre : https://zestedesavoir.com

                • [^] # Re: Formats non destructifs indispensables

                  Posté par  (site web personnel, Mastodon) . Évalué à 5.

                  Tout Ă  fait. Mais citer plus d'une source permet de montrer aussi l'histoire des mots et de leur utilisation. Par contre, pour l'actuel ça le fait pas. En la matiĂšre mĂȘme un dictionnaire ancien est valable.

                  « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

                  • [^] # Re: Formats non destructifs indispensables

                    Posté par  (site web personnel, Mastodon) . Évalué à 4.

                    Yep, ma remarque était généraliste, parce que plein de gens ne sont pas au courant de ces différence et pensent que les dictionnaires sont à peu prÚs interchangeables (ce qui était à peu prÚs vrai quand on cherchait dans un Larousse ou un Robert papier pas trop vieux chez soi).

                    La connaissance libre : https://zestedesavoir.com

            • [^] # Re: Formats non destructifs indispensables

              Posté par  (site web personnel) . Évalué à 8.

              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.

  • # Portable Document Format

    Posté par  (site web personnel) . Évalué à 6.

    Inutile de présenter le format PDF, également conçu par Adobe, normalisé et trÚs largement répandu.

    Je ne pense pas que la présentation soit inutile parce que ce n'est pas si simple.

    Qualifier un document PDF comme une image est dĂ©licat car ce format est bien plus qu'une image. Il y a pour commencer la notion de page qu'on n'a pas dans une image. Les PDF qu'on rencontre couramment peuvent contenir des formulaires. Un PDF peut mĂȘme contenir un programme exĂ©cutable, j'ai par exemple vu des documents PDF intĂ©grant une visionneuse 3D ainsi qu'un modĂšle 3D.

    Je pense que tu avais en tĂȘte le format PDF/A dont la spĂ©cification est limitĂ©e, mais il faut garder Ă  l'esprit que les PDF ne sont pas forcĂ©ment dans ce format.

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Portable Document Format

      Posté par  (site web personnel) . Évalué à 4.

      TIFF permet de faire des fichiers multi-pages.

    • [^] # Re: Portable Document Format

      Posté par  (site web personnel, Mastodon) . Évalué à 3. DerniĂšre modification le 26 juin 2023 Ă  17:56.

      Et le PDF garde le texte en texte, donc lisible par les dispositifs d’assistance et copiable en texte. Et il peut ĂȘtre transformĂ© en EPUB.

      Un texte image, mĂȘme sur plusieurs pages, reste de l’image donc pas lisible des dispositifs d’assistance, notamment.

      Perso, j’ai tendance Ă  plutĂŽt dire que le PDF est un genre de « photocopie » numĂ©rique, mais en plus riche et toutes proportions gardĂ©es rapport Ă  ce qui figure ci-dessus.

      Cela dit, en informatique le terme « image » a aussi un autre sens qui serait plutĂŽt synonyme de « clone » ou de copie identique que de dessin par exemple. En ce sens, le PDF est effectivement une « image » du document.

      « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

      • [^] # Re: Portable Document Format

        Posté par  (site web personnel) . Évalué à 3.

        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 !

      • [^] # Re: Portable Document Format

        Posté par  (site web personnel) . Évalué à 6. DerniĂšre modification le 26 juin 2023 Ă  18:51.

        Et le PDF garde le texte en texte, donc lisible par les dispositifs d’assistance et copiable en texte

        moui, bah ça c'est souvent dans le désordre :/
        nombre de fois, j'ai tenté de copier le contenu :

        • pas de bol, ya que l'image scannĂ©e qui est intĂ©grĂ©e :/
        • le texte ressort en globiboulga oĂč les lettres sont
        • pour copier un tableau texte, c'est quasi mission impossible : quand j'ai de la chance, les colonnes sont simplement passĂ©es Ă  la ligne (avec un ou plusieurs sauts de ligne o_O)
        • rarement de copier/coller d'image rĂ©ussi :/

        bref, pour moi, PDF est un format d'impression, pas pour un stockage rĂ©versible permettant d'accĂ©der facilement au contenu
 pdf2txt s'en sort peut-ĂȘtre mieux (mais gĂ©nĂ©ralement, j'ai pas besoin de l'intĂ©gralitĂ© du doc')

        • [^] # Re: Portable Document Format

          Posté par  (site web personnel, Mastodon) . Évalué à 4. DerniĂšre modification le 26 juin 2023 Ă  19:00.

          Ah mais ça dépend aussi beaucoup de la qualité technique du document d'origine. Et c'est surtout un format d'archive en effet.

          Je voulais surtout insister sur la diffĂ©rence entre le texte, qui peut, mĂȘme imparfaitement, ĂȘtre lu des dispositifs d'assistance, voire, ĂȘtre transformĂ© en EPUB et le texte image qui ressemble visuellement Ă  du texte mais n'en est pas. Et c'est une diffĂ©rence absolument fondamentale.

          « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

        • [^] # Re: Portable Document Format

          Posté par  (site web personnel) . Évalué à 4. DerniĂšre modification le 27 juin 2023 Ă  10:36.

          Pour sortir les images, pdfimages -all.

    • [^] # Re: Portable Document Format

      Posté par  (site web personnel) . Évalué à 4.

      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. :-)

    • [^] # Re: Portable Document Format

      Posté par  (site web personnel) . Évalué à 2.

      Au sujet des PDF 3D, il me semble que c'est les lecteurs qui intĂšgrent la visionneuse 3D, pas le fichier donc il faut un lecteur pdf sachant lire le pdf 3d et d'ailleurs je n'en connais pas qui s'installent nativement sur linux et encore moins qui seraient libre.

      De plus les formats 3d compatible pdf sont des maillages, donc avec perte d'information et aucun retour en arriĂšre (ou avec des suppositions) si on part d'un modĂšle 3d volumique.

  • # Consommation de mĂ©moire ?

    Posté par  (site web personnel) . Évalué à 1.

    MĂȘme si c'est un peu une niche, mais c'est ce qui m'intĂ©resse en ce moment, je constate que rien que charger du JPEG sur un microcontrĂŽleur type RP2040 / Raspberry Pi Pico avec 256 KiB charge pas mal la mule au niveau RAM et CPU, ça donne quoi avec tous ces mirifiques formats type WEBP ou JPEG-XL ?

  • # PrĂ©sentation de Jpeg-XL

    Posté par  . Évalué à 3.

  • # Vous pratiquez le JPEG2000 sans le savoir

    Posté par  . Évalué à 4.

    Vous avez tous dĂ©jĂ  utilisĂ© ce format JPEG2000 sans le savoir, tout simplement en vous rendant dans une salle de cinĂ©ma : le format du cinĂ©ma numĂ©rique utilise en effet ce type de codage JPEG2000 avec un codage sans perte de chaque image (indĂ©pendemment des autres, Ă  la diffĂ©rence des formats video comme le MPEG)


    • [^] # Re: Vous pratiquez le JPEG2000 sans le savoir

      Posté par  (site web personnel) . Évalué à 5.

      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.

    • [^] # Re: Vous pratiquez le JPEG2000 sans le savoir

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

       le format du cinĂ©ma numĂ©rique utilise en effet ce type de codage JPEG2000 avec un codage sans perte de chaque image

      Le format cinĂ©ma numĂ©rique (DCP) utilise en effet JPEG2000 mais avec perte, de ce que je sais (JPEG2000, comme beaucoup de formats de nos jours, pouvant faire les deux), mĂȘme si c'est avec une compression acceptable pour Ă©viter les artefacts visibles. Cela rend d'ailleurs les films dĂ©jĂ  bien assez gros (alors imaginez en totalement sans perte).

      De mémoire, si un film d'animation simple peut faire une trentaine de GiB, un film cinéma typique (c'est à dire filmé, avec des acteurs) fera une centaine de GiB (et un film 3D peut aller dans les 200 ou 300GiB.
      "De mĂ©moire" car j'ai travaillĂ© dans ce milieu, il y a quelques annĂ©es. Et mĂȘme si je n'ai pas vĂ©rifiĂ© moi-mĂȘme, on m'avait bien dit que c'Ă©tait du JPEG2000 avec perte.

      Par contre la NASA a utilisé aussi du JPEG2000 pour des images astronomiques et là je me demande s'ils n'encodent pas sans perte.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Vous pratiquez le JPEG2000 sans le savoir

        Posté par  . Évalué à 4. DerniĂšre modification le 23 juillet 2023 Ă  17:57.

        Hello :)

        JPEG2000 avec perte.
        lĂ  je me demande s'ils n'encodent pas sans perte.

        Pour les copies projections, oui, avec perte.
        Pour les archives type IMF, c'est sans (réversible).

        De mémoire, si un film d'animation simple peut faire une trentaine de GiB, un film cinéma typique (c'est à dire filmé, avec des acteurs) fera une centaine de GiB (et un film 3D peut aller dans les 200 ou 300GiB.

        Pour le coup, tu peux doubler les chiffres :-D

        Shrek fait autour des 65G
        Astérix - Le Secret de la potion magique : ~70G
        Demon's Slayer : 68G
        Prince d'Egypte : 72G

        Pour les films classiques (sans 3D) :
        Knives Out : ~250G
        No Time To Die (4K / 2D): ~600G
        Ad Astra (4K / 2D): ~500G
        Avatar 2 : ~800-900G (tout dépend de la version, là, c'est la version 3D 48 fps)

        Il faudrait que je fasse des stats sur les poids de maintenant
        (voire mĂȘme des stats sur le poids Ă  travers le temps)

        • [^] # Re: Vous pratiquez le JPEG2000 sans le savoir

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          LĂ  oĂč je bossais, c'Ă©tait une association de cinĂ©mas d'art et d'essai et les distributeurs qui avaient des contrats avec l'association n'Ă©taient pas les plus gros (qui ne veulent passer que par les gros services, type Globecast, ou simplement envoyer des disques par coursiers car certains des plus gros distributeurs n'ont simplement aucune confiance en des intermĂ©diaires de service de tĂ©lĂ©chargement de DCP).

          Donc il est trĂšs vraisemblable que les DCPs que j'ai vu passer Ă©taient plutĂŽt la partie "petite taille" du marchĂ© total (petits films, beaucoup d'indĂ©s, moins longs que les blockbusters qui de nos jours font 2h voire 3h; peu de 4K
 3D encore plus rares
). 😄

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # la gif89a est vivante !

    Posté par  (Mastodon) . Évalué à 2.

  • # Format ouvert et spĂ©cifications ouvertes

    Posté par  (site web personnel, Mastodon) . Évalué à 7. DerniĂšre modification le 21 juillet 2023 Ă  12:12.

    Je ne suis pas sûr de comprendre la différence, mais Drew DeVault disait récemment que le JPEG-XL n'avait pas de spécifications ouvertes. Je vois que (une partie de) ces derniÚres coûtent 200 francs suisses sur le site de l'ISO et j'imagine qu'elles ne sont pas en Creative Commons, mais une fois qu'on les a implémentées dans un logiciel libre, en quoi le caractÚre "fermé" des specs pourrait nuire au caractÚre "ouvert" du format (si on considÚre le JPEG-XL comme un "format ouvert") ?

    • [^] # Re: Format ouvert et spĂ©cifications ouvertes

      Posté par  . Évalué à 2. DerniĂšre modification le 21 juillet 2023 Ă  17:14.

      Désolé, j'ai moinsé, mais c'est juste un doigt trop gros qui à cliqué au lieu de faire défiler l'article sur mon smartphone, pas l'expression de mon avis sur cette intervention.

    • [^] # Re: Format ouvert et spĂ©cifications ouvertes

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Je sais pas si tu fais beaucoup de dĂ©veloppement, mais mĂȘme s'il arrive bien entendu de s'inspirer de code existant, lire du code complexe pour le rĂ©implĂ©menter n'a rien d'une partie de plaisir et surtout n'a rien de simple.

      TrĂšs souvent, dans un cas tel que de la prise en charge de format de fichier ou de protocole, il sera mĂȘme bien plus simple de faire de l’ingĂ©nierie inverse directement sur des Ă©chantillons de fichiers existants que d'essayer de lire 5000 lignes de code existant.

      Le coup du "Ça existe dĂ©jĂ  dans le logiciel libre X, pourquoi vous reprenez pas juste le code?" est probablement l'une des dĂ©clarations les plus vaines et frustrantes qu'on lit rĂ©guliĂšrement sur le web, de gens qui ne dĂ©veloppent pas (ou peu).

      Bien sĂ»r, l'existence de code, ça aide. Mais lire du code complexe n'est absolument pas Ă©quivalent Ă  une spec qui dira la mĂȘme chose en un paragraphe de texte simple qu'un code qui fera des boucles, des renvois en fonctions, des break, manipulera probablement des octets (on parle de donnĂ©es) et des bits (flags de bit, etc. typique dans les formats de fichiers), possiblement avec des optimisations de traitement super abscons et opaques qu'on doit relire 5 fois avant de comprendre ce que ça fait et dont on aura dĂ©jĂ  oubliĂ© Ă  moitiĂ© la logique le lendemain quand on relira le mĂȘme code (et complĂštement une semaine aprĂšs). Parce que dĂšs qu'on se met Ă  manipuler des octets et des bits, il y a toujours Ă©normĂ©ment de trucs super pas clairs pour permettre des optimisations en lecture-Ă©criture (la diffĂ©rence entre un algorithme dit "naĂŻf" qui est celui implĂ©mentĂ© en premier car il paraĂźt logique et qui est donc aussi simple Ă  lire, et celui optimisĂ© quand on se rend compte que son algo naĂŻf est aussi super lent — genre 50 fois plus lent qu'un algo optimisĂ© mais abscons — quand on doit traiter de vrais donnĂ©es du monde rĂ©el, donc des images super mĂ©ga grosses).

      Et ça c'est sans parler du fait qu'on parle d'image et de couleur, donc avec en plus de la conversion de modÚles de couleur, parfois des trucs bizarres dans la gestion des canaux, etc.

      une fois qu'on les a implémentées dans un logiciel libre, en quoi le caractÚre "fermé" des specs pourrait nuire au caractÚre "ouvert" du format (si on considÚre le JPEG-XL comme un "format ouvert") ?

      Donc non, on ne peut pas dire qu'un format sans specs accessibles soit "ouvert". Une implémentation libre de specs fermées n'est pas comparable à des specs.

      Et c'est sans compter qu'une implémentation peut avoir des bugs. Sans accÚs à la spec, si on prend pour argent comptant ce qu'une implémentation particuliÚre fait, on peut avoir des soucis.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Format ouvert et spĂ©cifications ouvertes

        Posté par  . Évalué à 2.

        Donc non, on ne peut pas dire qu'un format sans specs accessibles soit "ouvert". Une implémentation libre de specs fermées n'est pas comparable à des specs.

        Les specs de JPEG-XL me semblent accessibles sans restriction à qui veut bien payer (~ 240€). Si c'est payant ça n'est plus "open" ? (question naïve, je n'y connais rien)

        • [^] # Re: Format ouvert et spĂ©cifications ouvertes

          Posté par  (site web personnel) . Évalué à 3.

          Si c'est payant ça n'est plus "open" ? (question naïve, je n'y connais rien)

          le respect de la dĂ©finition de format ouvert induit qu'il y a des spĂ©cifications accessibles selon une licence et des termes raisonnable et non discriminatoire. Si c'est redistribuable sous condition prĂ©alable d'avoir payĂ© une somme raisonnable, ça peut le faire (on va dire que c'est raisonnable de se cotiser Ă  plusieurs ou trouver un financement pour < 250 €). Si c'est non redistribuable et que pour y accĂ©der, faut payer ne serait-ce que 240 €, pour chaque personne qui a besoin de la spĂ©cification, bin lĂ , la question se pose (ça fait un peu discriminatoire, non ?)

          • [^] # Re: Format ouvert et spĂ©cifications ouvertes

            Posté par  . Évalué à 2.

            Ok. Quoiqu'il en soit, s'agissant de specs et non d'une licence d'utilisation, ça ne me paraßt pas un réel obstacle à l'adoption du JPEG-XL, d'autant qu'en plus une implémentation de référence est disponible. gratuitement.

  • # Petits rappels trĂšs utiles

    Posté par  (site web personnel) . Évalué à 1.

    Merci pour cet article qui permet de petits rappels trÚs utiles et des mises à niveau fort appréciables

    François

    "Il n'y a de richesse que d'hommes" (J. Bodin) - Trésorier de l'association GUTenberg (https://www.gutenberg-asso.fr/)

Suivre le flux des commentaires

Note : les commentaires appartiennent Ă  celles et ceux qui les ont postĂ©s. Nous n’en sommes pas responsables.