Des formats d'image

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

  Posté par Thomas Debesse (site web personnel) le 25 juin 2023 à 00:17. É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) :

  

  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 marzoul le 25 juin 2023 à 13:04. É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 orfenor le 25 juin 2023 à 16:37. Évalué à 6.

    

    Tu n'utilises pas QOI ?

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

    Posté par orfenor le 25 juin 2023 à 17:26. É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 ted (site web personnel) le 26 juin 2023 à 08:14. É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 orfenor le 26 juin 2023 à 11:03. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 16:04. É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 Thomas Debesse (site web personnel) le 26 juin 2023 à 18:55. É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 Thomas Debesse (site web personnel) le 26 juin 2023 à 22:01. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 17:51. É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 mahikeulbody le 25 juin 2023 à 10:05. É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 Xanatos le 25 juin 2023 à 12:29. É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 Psychofox (Mastodon) le 26 juin 2023 à 10:55. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 11:04. É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 Psychofox (Mastodon) le 26 juin 2023 à 11:20. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 11:23. É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 orfenor le 26 juin 2023 à 11:37. É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 mahikeulbody le 26 juin 2023 à 13:10. É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 orfenor le 26 juin 2023 à 15:15. Évalué à 3.

            

            Je voulais dire comparé à WebP

          • [^] # Re: JPEG-XL

            Posté par ted (site web personnel) le 26 juin 2023 à 17:17. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 17:40. É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 cosmocat le 27 juin 2023 à 09:25. É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 cosmocat le 27 juin 2023 à 09:21. É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 BAud (site web personnel) le 25 juin 2023 à 11:18. É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)

  • [^] # Re: comparaison n'est pas raison

    Posté par cosmocat le 27 juin 2023 à 09:02. Évalué à 10.

    

    Si tu aimes bien les images:

    

• # Avis sur HEIF

  Posté par Funix (site web personnel, Mastodon) le 25 juin 2023 à 12:55. É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 FDF (site web personnel) le 25 juin 2023 à 14:35. É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 Funix (site web personnel, Mastodon) le 25 juin 2023 à 14:55. É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 orfenor le 25 juin 2023 à 15:56. É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 Xanatos le 25 juin 2023 à 14:37. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 10:20. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 10:43. É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 Funix (site web personnel, Mastodon) le 27 juin 2023 à 07:44. É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 mahikeulbody le 27 juin 2023 à 08:25. É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 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 10:13. É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 nud le 27 juin 2023 à 10:51. É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 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 10:07. É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 FDF (site web personnel) le 28 juin 2023 à 00:19. É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 Funix (site web personnel, Mastodon) le 28 juin 2023 à 06:34. É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 mahikeulbody le 28 juin 2023 à 08:23. É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 🚲 Tanguy Ortolo (site web personnel) le 28 juin 2023 à 09:19. É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 mahikeulbody le 28 juin 2023 à 09:32. É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 🚲 Tanguy Ortolo (site web personnel) le 28 juin 2023 à 09:17. É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 Jehan (site web personnel, Mastodon) le 23 juillet 2023 à 16:45. É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 BAud (site web personnel) le 23 juillet 2023 à 17:09. É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 Jehan (site web personnel, Mastodon) le 24 juillet 2023 à 01:29. É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 FDF (site web personnel) le 28 juin 2023 à 11:13. É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 abriotde le 24 juillet 2023 à 09:19. É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.

          • [^] # Re: Avis sur HEIF

            Posté par Funix (site web personnel, Mastodon) le 25 juillet 2023 à 05:46. É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 🚲 Tanguy Ortolo (site web personnel) le 25 juillet 2023 à 16:31. É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 Funix (site web personnel, Mastodon) le 25 juillet 2023 à 17:12. É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 🚲 Tanguy Ortolo (site web personnel) le 25 juillet 2023 à 17:18. Évalué à 3.

                  

                  Eh bien on est d'accord en fait. C'était quoi déjà le sujet de toute cette discussion ?

                  • [^] # Re: Avis sur HEIF

                    Posté par Funix (site web personnel, Mastodon) le 25 juillet 2023 à 17:28. Évalué à 3.

                    

                    ben oui, tout ce fil pour en arriver là :-)

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

              • [^] # Re: Avis sur HEIF

                Posté par Maderios le 26 juillet 2023 à 21:52. É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 mahikeulbody le 26 juillet 2023 à 23:10. É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 SpaceFox (site web personnel, Mastodon) le 27 juillet 2023 à 10:24. É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ées¹. 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 🚲 Tanguy Ortolo (site web personnel) le 27 juillet 2023 à 09:38. É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 Maderios le 27 juillet 2023 à 10:13. É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 SpaceFox (site web personnel, Mastodon) le 27 juillet 2023 à 10:33. É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 Micromy (site web personnel) le 25 juin 2023 à 13:31. É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 !…) !

  • [^] # Re: Titre de la dépêche ambigu

    Posté par Tonton Th (site web personnel, Mastodon) le 25 juin 2023 à 15:05. Évalué à 4.

    

    Mon "préféré" était le TGA car au moins on pouvait avoir des images en… 256 couleurs (wahou !…) !

    Euh, Tiff et TGA jusque à 16 millions, PCX et BMP, 256 à palette.

    • [^] # Re: Titre de la dépêche ambigu

      Posté par Benoît Sibaud (site web personnel) le 25 juin 2023 à 15:11. Évalué à 7. Dernière modification le 25 juin 2023 à 15:13.

      

      Autres formats pour dinos :
      https://fr.m.wikipedia.org/wiki/X_BitMap
      Ce format est avec GIF le premier à avoir été utilisable dans les pages web. Comme il est obsolète, son support est progressivement retiré des navigateurs Web.
      Et
      https://fr.m.wikipedia.org/wiki/X_PixMap
      Obsolète, il est souvent remplacé par les formats Portable pixmap.

  • [^] # Re: Titre de la dépêche ambigu

    Posté par dcp le 26 juin 2023 à 11:36. Évalué à 4.

    

    Dans la série "Les vieux de la vieille" :

    https://en.wikipedia.org/wiki/DEGAS_(software) (Format *.pc1 …)
    https://en.wikipedia.org/wiki/NEOchrome (Format *.neo)

    Et le fameux Spectrum 512 https://doudoroff.com/atari/spectrum.html qui permettait d'afficher 512 couleurs sur le STF (en changeant la palette des 16 couleurs autorisés à chaque balayage horizontal de l'écran cathodique, rigolez pas les jeunes).

• # Merci

  Posté par J Avd le 25 juin 2023 à 17:16. É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 Christophe Duparquet (site web personnel) le 26 juin 2023 à 08:49. É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 Thomas Douillard le 26 juin 2023 à 09:51. É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 pulkomandy (site web personnel, Mastodon) le 26 juin 2023 à 16:25. É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 xryl669 le 20 juillet 2023 à 12:32. Évalué à 1.

      

      Le bit est incompressible

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

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

    Posté par nud le 26 juin 2023 à 11:07. É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 Tit le 26 juin 2023 à 12:14. É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 Yth (Mastodon) le 26 juin 2023 à 09:11. É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 Yth (Mastodon) le 26 juin 2023 à 09:20. É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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 26 juin 2023 à 09:54. É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 ted (site web personnel) le 26 juin 2023 à 10:36. É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 Dring le 26 juin 2023 à 10:53. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 10:54. É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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 26 juin 2023 à 11:53. É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 Pierre Tramal (site web personnel) le 26 juin 2023 à 13:53. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 14:48. Évalué à 5. Dernière modification le 26 juin 2023 à 14:48.

            

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

            • [^] # Re: PNG encore utile.

              Posté par Pierre Tramal (site web personnel) le 26 juin 2023 à 22:35. Évalué à 1.

              

              Pour une distribution via HTTP, pour une favicon ou un logo de site Web par exemple, c'est complètement transparent avec le Content-encoding.

        • [^] # Re: PNG encore utile.

          Posté par Pierre Tramal (site web personnel) le 26 juin 2023 à 13:55. É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 orfenor le 26 juin 2023 à 11:06. É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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 26 juin 2023 à 11:55. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 10:30. É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 ted (site web personnel) le 26 juin 2023 à 10:43. Évalué à 2.

      

      Correction effectuée

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

  • [^] # Re: PNG encore utile.

    Posté par orfenor le 26 juin 2023 à 11:08. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 11:13. É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 nud le 26 juin 2023 à 23:26. É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 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 10:14. Évalué à 3.

          

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

          • [^] # Re: PNG encore utile.

            Posté par 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 16:01. É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 nud le 27 juin 2023 à 17:00. É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 Yth (Mastodon) le 28 juin 2023 à 09:39. É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 🚲 Tanguy Ortolo (site web personnel) le 28 juin 2023 à 10:14. É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 🚲 Tanguy Ortolo (site web personnel) le 28 juin 2023 à 10:53. É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 🚲 Tanguy Ortolo (site web personnel) le 28 juin 2023 à 10:15. É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 Yth (Mastodon) le 28 juin 2023 à 11:58. É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 pulkomandy (site web personnel, Mastodon) le 27 juin 2023 à 18:28. É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 cosmocat le 27 juin 2023 à 20:22. Évalué à 2.

              

              Surle sujet : https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/mobilepresent?pli=1#slide=id.gde87dfbe27_0_43

• # Et la compression fractale ?

  Posté par Dring le 26 juin 2023 à 10:19. É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 ?

  • [^] # Re: Et la compression fractale ?

    Posté par 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 10:32. Évalué à 6.

    

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

  • [^] # Re: Et la compression fractale ?

    Posté par BAud (site web personnel) le 26 juin 2023 à 10:42. Évalué à 2. Dernière modification le 26 juin 2023 à 10:43.

    

    tu veux parler de Fractal compression et en français compression fractale ?

    sinon, tu peux aussi chercher avec « wavelets »

    sur mon 486 DX / 16 Mo de l'époque, une image couleur 100x100 avais mis 24h o_O pour la compression, l'affichage était plus rapide… (5 à 10 min je crois /o\)

    • [^] # Re: Et la compression fractale ?

      Posté par Dring le 26 juin 2023 à 11:00. Évalué à 2.

      

      Oui, je parle de ça. Mais quand je regarde les articles, je retrouve pas le soft que j'utilisais à l'époque. Y'a une référence à la société Iterated Systems. Je pense que j'avais sans doute récupérer une version de leur logiciel.

      Oui, très lent à la compression, très lent à la décompression, mais incroyablement efficace, à une époque ou internet c'était "pour les riches ou les universités américaines" et on devait se contenter des BBS ou du Minitel, donc avec des débits horribles.

      Comme j'ai pu le lire à gauche à droite, l'idée a été tuée par :
      - le fait que y'avait rien pour lire ces images à part un soft payant et cher
      - l'arrivée de l'ADSL
      - l'arrivée de JPEG qui présentait un meilleur compromis taille / durée de traitement

      • [^] # Re: Et la compression fractale ?

        Posté par BAud (site web personnel) le 26 juin 2023 à 11:34. Évalué à 2.

        

        je retrouve pas le soft que j'utilisais à l'époque

        tu peux réessayer avec des logiciels plus actuels ;-) j'ai trouvé :

        • https://github.com/topics/fractal-compression
        • https://github.com/xabarass/fast-fractal-compression basé sur une 1^ère version par kennberg
        • https://github.com/mannyray/fractalMapping
        • https://github.com/popa13/Fractal-Image-Compression
        • https://github.com/procrastimax/fractalcompression
        • https://github.com/c00kiemon5ter/Fractal-Image-Compression
        • https://github.com/pvigier/fractal-image-compression et papier sur compression fractale sur son blog
        • https://github.com/k-t-l-h/FractalCompression
        • et doit y en avoir d'autres :-) https://github.com/search?q=fractal+compression

        sur gitlab, je ne vois qu'un projet https://gitlab.com/explore/projects/topics/Fractal+compression

  • [^] # Re: Et la compression fractale ?

    Posté par orfenor le 26 juin 2023 à 11:09. Évalué à 2.

    

    Pareil. Dans ma mémoire, c'était une compression avec des ondelettes, vers 1996.

    • [^] # Re: Et la compression fractale ?

      Posté par BAud (site web personnel) le 26 juin 2023 à 11:15. Évalué à 2.

      

      vers 1996

      voire 93 ou plutôt 94 (j'étais encore au bât V4 en 2A :p)

• # Et le format BPG

  Posté par bcag2 (site web personnel) le 26 juin 2023 à 13:43. É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 orfenor le 26 juin 2023 à 15:20. Évalué à 5.

    

    BPG a été rendu obsolète par FLIF, lui même rendu obsolète par JPEGXL

• # Formats non destructifs indispensables

  Posté par Maderios le 26 juin 2023 à 15:19. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 15:32. É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 Maderios le 26 juin 2023 à 16:40. É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 Tonton Th (site web personnel, Mastodon) le 28 juin 2023 à 09:40. É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 nud le 28 juin 2023 à 11:23. É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 Jean Roc Morreale le 03 juillet 2023 à 15:06. É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 mahikeulbody le 03 juillet 2023 à 17:18. É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 Jean Roc Morreale le 04 juillet 2023 à 08:48. É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 SChauveau le 28 juillet 2023 à 17:50. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 15:34. É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 Maderios le 26 juin 2023 à 16:36. Évalué à 1.

      

      dans l'art, sans majuscule

      J'aurais pu préciser "Arts plastiques"

      • [^] # Re: Formats non destructifs indispensables

        Posté par 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 17:41. É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 Maderios le 26 juin 2023 à 22:42. É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 orfenor le 27 juin 2023 à 10:14. Évalué à 3.

            

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

            • [^] # Re: Formats non destructifs indispensables

              Posté par Maderios le 27 juin 2023 à 11:30. É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 orfenor le 27 juin 2023 à 12:53. Évalué à 4.

                

                ça m'interresse encore plus !
                on peut en voir qq part ?

                • [^] # Re: Formats non destructifs indispensables

                  Posté par Maderios le 27 juin 2023 à 13:06. Évalué à -1.

                  

                  Impossible, anonymat sur le Net, oblige…

          • [^] # Re: Formats non destructifs indispensables

            Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 27 juin 2023 à 10:31. É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 Maderios le 27 juin 2023 à 11:55. É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 SpaceFox (site web personnel, Mastodon) le 27 juin 2023 à 16:55. É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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 27 juin 2023 à 17:16. É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 SpaceFox (site web personnel, Mastodon) le 27 juin 2023 à 17:34. É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 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 10:35. É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 ted (site web personnel) le 26 juin 2023 à 17:44. É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 Christophe "CHiPs" PETIT (site web personnel) le 26 juin 2023 à 17:46. Évalué à 4.

    

    TIFF permet de faire des fichiers multi-pages.

  • [^] # Re: Portable Document Format

    Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 26 juin 2023 à 17:53. É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 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 17:55. É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 BAud (site web personnel) le 26 juin 2023 à 18:50. É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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 26 juin 2023 à 18:58. É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 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 10:36. Évalué à 4. Dernière modification le 27 juin 2023 à 10:36.

        

        Pour sortir les images, pdfimages -all.

  • [^] # Re: Portable Document Format

    Posté par 🚲 Tanguy Ortolo (site web personnel) le 26 juin 2023 à 17:53. É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 rockn (site web personnel) le 27 juin 2023 à 11:07. É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 Christophe "CHiPs" PETIT (site web personnel) le 26 juin 2023 à 17:51. É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 ?

  • [^] # Re: Consommation de mémoire ?

    Posté par cosmocat le 27 juin 2023 à 12:08. Évalué à 3.

    

    ça va pas répondre à ta question mais ça va te donner quelques indices:
    https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.g99b14c4dfb_0_7

    https://cloudinary.com/blog/contemplating-codec-comparisons#decoding_speed

    https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs#computational_complexity

• # Présentation de Jpeg-XL

  Posté par cosmocat le 27 juin 2023 à 10:39. Évalué à 3.

  

  Une présentation assez intéressante de Jpeg-XL:
  https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gae1d3c10a0_0_17

• # Vous pratiquez le JPEG2000 sans le savoir

  Posté par fred le 27 juin 2023 à 13:49. É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 🚲 Tanguy Ortolo (site web personnel) le 27 juin 2023 à 14:41. É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 Jehan (site web personnel, Mastodon) le 23 juillet 2023 à 15:43. É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 Prae le 23 juillet 2023 à 17:57. É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 Jehan (site web personnel, Mastodon) le 24 juillet 2023 à 02:01. É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 Tonton Th (site web personnel, Mastodon) le 29 juin 2023 à 12:29. Évalué à 2.

  

  Et c'est pas moi qui le dit…

  https://linuxfr.org/news/vingt-cinq-ans-de-linuxfr-org#comment-1928847

  • [^] # Re: la gif89a est vivante !

    Posté par Benoît Sibaud (site web personnel) le 29 juin 2023 à 13:47. Évalué à 3.

    

    Le ou la gif ou jif ?

    • [^] # Re: la gif89a est vivante !

      Posté par Tonton Th (site web personnel, Mastodon) le 29 juin 2023 à 16:37. Évalué à 2.

      

      Dégainer deux jours en avance, c'est un privilège de modérateur ?

  • [^] # Re: la gif89a est vivante !

    Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 29 juin 2023 à 14:24. Évalué à 4.

    

    Ben, faut dire, je ne connais pas de moyen plus simple pour faire un truc animé et accepté partout.

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: la gif89a est vivante !

      Posté par nud le 29 juin 2023 à 16:49. Évalué à 2.

      

      Le monde du web semble avoir décidé d'utiliser du webm pour cela, mais il faut alors utiliser un tag <video> et pas <img>, ce qui aurait nécessité un patch minime du site.

      • [^] # Re: la gif89a est vivante !

        Posté par Benoît Sibaud (site web personnel) le 29 juin 2023 à 17:19. Évalué à 3.

        

        Minime je ne suis pas sûr, vu qu'il faut soit laisser passer du balisage HTML, soit étendre markdown. En tout l'entrée existe dans le suivi : https://linuxfr.org/suivi/idee-de-balisage-audio-et-video-en-markdown

        • [^] # Re: la gif89a est vivante !

          Posté par nud le 29 juin 2023 à 17:39. Évalué à 2. Dernière modification le 29 juin 2023 à 17:39.

          

          Du markdown pour le logo du site en haut à gauche? Vraiment?

          À mon avis on parle pas du même truc.

          • [^] # Re: la gif89a est vivante !

            Posté par Benoît Sibaud (site web personnel) le 29 juin 2023 à 20:27. Évalué à 3.

            

            Ni l'un ni l'autre alors, le logo est choisi parmi les images disponibles dans une liste, et affiché avec la balise img.

            • [^] # Re: la gif89a est vivante !

              Posté par nud le 30 juin 2023 à 14:15. Évalué à 3.

              

              En fait si c'était juste un tag <img> comme dans la liste des logos ce serait facile (il suffit littéralement de mettre un if dans le template et de mettre un tag <video> s'il s'agit d'une extension de vidéo - j'ai vérifié) mais le logo principal du site est en fait affiché comme arrière-plan de l'élément <h1> en CSS. Afficher une vidéo impliquerait dès lors de modifier le markup pour introduire un tag <video>, ce qui devient tout de suite beaucoup plus contraignant dans la mesure où ça implique aussi de modifier les feuilles de style.

              Mais comme apparemment le webp animé existe on est peut-être sauvés de la contrainte de tout faire en 256 couleurs comme avec les gif animés.

      • [^] # Re: la gif89a est vivante !

        Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 29 juin 2023 à 19:32. Évalué à 3.

        

        On peut faire compliqué, en effet. Mais le simple qui te prend dix minutes tests compris, ça me paraît bien.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: la gif89a est vivante !

        Posté par 🚲 Tanguy Ortolo (site web personnel) le 30 juin 2023 à 08:43. Évalué à 4.

        

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

        • [^] # Re: la gif89a est vivante !

          Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 30 juin 2023 à 09:31. Évalué à 3.

          

          Je sais pas faire. Mais ce serait un truc à apprendre en effet.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: la gif89a est vivante !

          Posté par Benoît Sibaud (site web personnel) le 30 juin 2023 à 09:34. Évalué à 4.

          

          On peut déterrer le FLI/FLC sinon. https://en.m.wikipedia.org/wiki/FLIC_(file_format)

          • [^] # Re: la gif89a est vivante !

            Posté par devnewton 🍺 (site web personnel) le 01 juillet 2023 à 14:23. Évalué à 4.

            

            Pas besoin de sortir la pelle, le format ase utilisé par Libresprite est bien vivant et est basé sur fli/flc :-)

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

• # Format ouvert et spécifications ouvertes

  Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 21 juillet 2023 à 12:09. É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 Frédéric Blanc le 21 juillet 2023 à 17:14. É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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 21 juillet 2023 à 17:20. Évalué à 4.

      

      J'ai plussé pour compenser :)

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

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

      Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 22 juillet 2023 à 15:14. Évalué à 2.

      

      Tu es tout pardonné !

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

    Posté par Jehan (site web personnel, Mastodon) le 23 juillet 2023 à 16:04. É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 mahikeulbody le 23 juillet 2023 à 17:09. É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 BAud (site web personnel) le 23 juillet 2023 à 17:33. É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 mahikeulbody le 23 juillet 2023 à 18:31. É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 François Druel (site web personnel) le 22 juillet 2023 à 13:53. É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.