Les formats d’image classiques datent des années 1990 : après le format GIF en 1987, sont apparus le JPEG en 1992, le PNG en 1996 et le SVG en 1998. Leur adoption progressive s’est faite dans le contexte de la première guerre des navigateurs.
Ces formats couvrant à peu près tous les usages, les choses en sont restées là pendant plus de dix ans. Mais le paysage a commencé à changer dans les années 2010, avec l’introduction d’un nouveau format d’image moderne, WebP, pensé pour répondre à tous les besoins courants et pouvoir supplanter à la fois JPEG et PNG. Depuis, les nouveautés s’enchaînent, avec HEIF en 2015, AVIF en 2019 et JPEG XL en 2022.
Voici de quoi y voir plus clair.
Sommaire
Formats d'images matricielles
GIF – Graphics Interchange Format
Publié en 1987, avant même l’invention du Web, le format GIF permet de compresser sans perte une image avec une palette comptant au maximum 256 couleur et une transparence tout-ou-rien.
Le format GIF a longtemps été le seul format largement supporté permettant de stocker des animations, et il est resté utilisé pour cela pendant une trentaine d’années. Aujourd’hui, cette fonctionnalité est disponible avec le format WebP, et GIF peut enfin prendre une retraite bien méritée.
GIF est pris en charge par tous les navigateurs et probablement tous les logiciels d’affichage et de traitement d’image. En revanche, ce format ne présente plus aucun intérêt pour un usage courant, puisqu’il a été complètement supplanté par PNG, qui est lui-même ringard.
JPEG – Joint Photographic Experts Group
Publié en 1992 comme norme ISO, le format JPEG sert à compresser des photos avec pertes. Il permet de représenter des images en niveau de gris sur 8 bits ou en RVB sur 24 bits. Il ne supporte aucun mode de transparence. Ce format peut être utilisé au sein d’un document PDF, ce qui est utile pour la composition de documents avec des images, par exemple en LaTeX compilé directement en PDF.
JPEG est pris en charge par tous les navigateurs et tous les logiciels d’affichage et de traitement d’image. Ceci dit, ce format ne présente plus aucun intérêt pour la plupart des usages courants, et peut être remplacé par WebP pour les nouvelles images.
PNG – Portable Network Graphics
Publié en 1996 par le W3C, le format PNG a été conçu pour remplacer GIF, qui souffrait de limitations techniques et de problèmes de brevets. Il permet de compresser sans perte une image avec une palette de 8 ou 256 couleurs, en niveau de gris sur 1 à 16 bits ou en RVB sur 8 ou 16 bits par canal, avec une transparence optionnelle par canal alpha sur 8 ou 16 bits.
Comme JPEG, ce format peut être utilisé dans un document PDF.
PNG est une recommandation du W3C, également reprise sous la forme d’une RFC puis d’une norme ISO. Il est pris en charge par tous les navigateurs et tous les logiciels d’affichage et de traitement d’image. Ceci dit, ce format ne présente plus aucun intérêt pour la plupart des usages courants, et peut être remplacé par WebP pour les nouvelles images.
Il a également été étendu par deux formats d’animation qui ont longtemps souffert d’une querelle qui explique l’utilisation persistante de l’antique format GIF :
- MNG – Multiple-image Network Graphics – initialement supporté par les logiciels Mozilla ;
- APNG – Animated PNG – aujourd’hui largement supporté.
JPEG 2000
Publié en… 2000, ce format visait à remplacer JPEG, avec une compression plus performante. L’accès payant à sa spécification, ainsi que des soupçons de problèmes de brevets, ont largement contribué à la très faible adoption de ce format.
Ce format a pourtant un intérêt anecdotique, puisqu’à l’instar de JPEG et PNG, il peut être utilisé dans un document PDF.
Le format JPEG 2000 est assez peu connu et donc supporté par peu de logiciels en dehors de ceux spécifiquement conçus avec le souci de pouvoir traiter des images dans un maximum de formats.
JBIG2 – Joint Bi-level Image Group
Publié également en 2000, ce format sert à compresser avec ou sans pertes des images en noir et blanc. Il s’agit ici de vrai noir et blanc, et non de niveaux de gris.
Ce rôle très spécifique limite beaucoup son utilisation, mais il reste intéressant pour stocker avec une efficacité redoutable des textes numérisés en très haute définition. Il peut également être intégré dans un document PDF, ce qui est très utile pour l’archivage de documents.
Comme JPEG 2000, JBIG2 est assez peu connu et supporté par peu de logiciels.
WebP
En 2010, Google est venu bousculer ce paysage à peu près stable, en proposant un format moderne, conçu pour s’imposer comme une solution universelle.
Dérivé du format vidéo VP8, WebP est donc un format ouvert, qui permet de compresser de façon efficace avec ou sans perte, en RVB sur 24 bits, avec un canal alpha optionnel (à noter que ce dernier peut être compressé sans perte même pour une image compressée avec pertes). Il permet également de stocker des animations.
Aujourd’hui, WebP est pris en charge par tous les navigateurs et par la majorité des logiciels d’affichage et de traitement d’image. Il peut déjà être considéré comme un format universel largement utilisable.
HEIC – HEVC dans un conteneur HEIF
Le format HEIF – High Efficiency Image File Format – est un conteneur, principalement conçu pour le stockage d’images compressées avec HEVC — High Efficiency Video Codec. L’ensemble est publié depuis 2015. Il permet de compresser avec ou sans perte, avec un canal alpha optionnel, et supporte les animations.
Ce format est une norme ISO, issue du travail du groupe MPEG, et souffre de problèmes de brevets. Il n’est pris en charge par aucun navigateur et seulement par certains logiciels d’affichage et de traitement d’image.
Ce format a peu de chance de réellement s’imposer, en dehors du cercle de certains environnements logiciels propriétaires spécifiques comme celui d’Apple.
AVIF – AV1 Image File Format
Publié en 2019 par l’Alliance for Open Media fondée par Amazon, Google, Cisco, Microsoft, Mozilla et Netflix, ce format utilise le conteneur HEIF pour stocker des images compressées avec AV1. Comme les autres formats modernes, il permet de compresser avec ou sans pertes les images en niveaux de gris et en couleur, avec un canal alpha optionnel, et supporte les animations. Il permet également l’intégration d’un profil de couleurs et le stockage de grandes gammes de couleurs, jusqu’à 12 bits par couleur.
Ce format est ouvert et disponible sans problème de brevet. Il est pris en charge par tous les navigateurs modernes et par certains logiciels d’affichage et de traitement d’image.
Il est peut-être un peu tôt pour en juger, mais ce format pourrait s’imposer avec une prise en charge assez large.
JPEG XL
Finalisé en 2022, ce format a été conçu par le groupe JPEG pour remplacer le format JPEG premier du nom. Il supporte l’ensemble des fonctionnalités modernes : niveaux de gris, couleur, alpha optionnel et animations, et apporte des fonctionnalités utiles pour des usages plus avancés, telles que le support des couleurs en CMJN, des espaces de couleurs larges ou encore les grandes gammes dynamiques. Ce format présente également une fonctionnalité qui apparaît particulièrement intéressante pour la compression d’images existantes, puisqu’il permet de recompresser sans nouvelles pertes une image JPEG, avec évidemment un gain d’espace de stockage.
C’est un format ouvert, apparemment disponible sans problème de brevets. Il commence à être pris en charge par des navigateurs, à savoir Firefox nightly et Safari, ainsi que par bon nombre de logiciels d’affichage et de traitement d’image dans leurs versions récentes.
En clair, ce format est un peu trop jeune pour qu’on puisse compter sur une large prise en charge, mais cela viendra sans doute dans les années à venir.
Formats d’images vectorielles
EPS – Encapsulated PostScript
Conçu par Adobe, le format PostScript encapsulé est dérivé du PostScript, qui a connu son heure de gloire il y a une ou deux décennies, pour le stockage d’images destinées à être intégrées dans un flux de production de documents.
Il était notamment utile pour intégrer des images vectorielles (ou non !) dans un document LaTeX. Il est aujourd’hui largement supplanté pour ces usages par le format PDF.
PDF – Portable Document Format
Inutile de présenter le format PDF, également conçu par Adobe, normalisé et très largement répandu. Je préciserai simplement qu’il permet entre autres de stocker des images vectorielles avec transparence. Il est utile dans cet usage pour stocker des schémas destinés à être intégrés dans un document, par exemple un document LaTeX compilé directement en PDF.
En revanche, son usage habituel étant plutôt celui du stockage de documents de plusieurs pages, il n'est pas utilisable pour intégrer des dessins dans une page Web. Il est bien supporté par tous les navigateurs modernes, mais plutôt dans une optique d’intégration de document externe.
SVG – Scalable Vector Graphics
Le format SVG a été publié en 1998 par le W3C. C’est le format standard d’images vectorielles, utilisé nativement par nombre de logiciels de dessin. Il est supporté par tous les navigateurs modernes et par la plupart des logiciels d’affichage d’image. Il est supporté par tous les logiciels de dessin vectoriel libre, et probablement également par les logiciels de dessin propriétaire puisqu’il serait assez indécent de fournir un logiciel de dessin qui ne puisse pas au minimum importer ce format standard.
Outils
Pour convertir des images d’un format matriciel à un autre, vous pouvez utiliser :
- ImageMagick ou GraphicsMagick ;
- les outils spécialisés pour chaque format, par exemple ceux de WebP.
Pour stocker des images matricielles JPEG, PNG ou JPEG 2000 en PDF, sans recodage, vous pouvez utiliser img2pdf. Je ne connais pas de solution simple pour stocker une image JBIG2 dans un document PDF. Pour convertir des dessins vectoriels en PDF, le plus simple est d’utiliser la fonctionnalité d’export PDF de son logiciel de dessin vectoriel. Celle d’Inkscape est utilisable en ligne de commande.
Conclusion
Photos
Pour stocker une photo existante, gardez l’image JPEG existante. Si vous avez des contraintes de stockage, utilisez JPEG XL. Pour publier une photo ou une création, oubliez JPEG et utilisez WebP. Ou, si vous voulez faire moderne, AVIF.
N’utilisez pas HEIC, ce format n’a pas été correctement conçu pour s’imposer et fait déjà partie des perdants.
Photos détourées
Pour stocker et diffuser une photo avec de la transparence (votre visage ?), utilisez WebP. Ou, si vous voulez faire dans la modernité, AVIF. Oubliez PNG, ce format n’est pas adapté et n’était utile dans ce domaine qu’avant l’arrivée de WebP qui a l’avantage d’être vraiment adapté à cet usage.
Dessins, BD, …
Pour stocker une image existante, vous pouvez bien garder le PNG existant. Si vous avez des contraintes de stockage, utilisez JPEG XL. Pour publier une image existante ou une création, utilisez WebP ou AVIF. Oubliez PNG, WebP en mode sans perte est juste mieux.
Dessins et schémas vectoriels
Pour le stockage comme pour la publication d’images vectorielles, le format standard SVG est presque toujours la meilleure option, sinon la seule. Si vous voulez utiliser un schéma dans un document LaTeX, le mieux est de l’exporter en PDF, en conservant le SVG original. Oubliez le PostScript encapsulé, ce format a été complètement supplanté par PDF pour ses cas d’usage.
Aller plus loin
- Guide des types et formats d'image, par Mozilla (353 clics)
- WebP (323 clics)
- JPEG XL (286 clics)
- SVG (254 clics)
- Formats supportés par ImageMagick (275 clics)
- Formats supports par GraphicsMagick (261 clics)
# WebP sans perte et exact (car tous les fichiers images ne codent pas rouge/vert/bleu/transparent)
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 10.
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
cwebpavec l’option-losslessne 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’outilcwebpil faut utiliser les options-lossless -exact.Mais qu’est ce que cette diablerie ? 😱️
Par défaut
cwebp -losslesspeut 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 . É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 . Évalué à 6.
Tu n'utilises pas QOI ?
[^] # Re: WebP sans perte et exact
Posté par orfenor . É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) . É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 . Évalué à 2.
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) . É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, Mastodon) . Évalué à 8.
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 ».
Ces formats d’image ne sont faits que pour le web à l’époque d’HTML 4. FTFY =)
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.jpgivy_alpha.jpgivy_gloss.jpgivy_norm.jpgblack-tiles-mossy_norm.jpgblack-tiles-mossy_norm.jpgblack-tiles-mossy_norm_alpha.jpgpk02_floor07.tgapk02_floor07_gloss.tgapk02_floor07_norm.tgapk02_light02a.tgapk02_light02a_glow.tgapk02_light02a_gloss.tgapk02_light02a_norm.tgace commentaire est sous licence cc by 4 et précédentes
[^] # Re: WebP sans perte et exact
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 26 juin 2023 à 22:01.
Petite correction :
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) . É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 . Évalué à 8.
Merci pour cet état des lieux.
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 . É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) . É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) . É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) . É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) . É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 à :
[^] # Re: JPEG-XL
Posté par orfenor . É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 . Évalué à 4. Dernière modification le 26 juin 2023 à 13:11.
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 . Évalué à 3.
Je voulais dire comparé à WebP
[^] # Re: JPEG-XL
Posté par ted (site web personnel) . Évalué à 3.
Tu confirmes qu'on gagne de place en jpeg-xl en partant d'un jpeg et sans ajouter des pertes? J'imaginais que dans ce cas précis, le changement de format n'apportait pas de gain de place, comme si on réorganisait juste les données dans un nouveau conteneur.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: JPEG-XL
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Oui, c'est conçu pour ça. Et je viens d'essayer, sur une image JPEG de 1,9 Mio, j'obtiens une image JPEG XL de 1,5 Mio sans perte supplémentaire.
C'est le gros intérêt du JPEG XL, la fonctionnalité qui semble anecdotique mais qui tue, en fait : on peut prendre une ensemble de millions de photos en JPEG, et bourrinement transcoder tout ça en JPEG XL sans risquer d'avoir des remords.
Mieux encore, JPEG XL est capable de se transcoder vers JPEG, toujours sans perte. Voire même, encore mieux, à condition d'avoir stocké les métadonnées d'origine, de reconstruire exactement le JPEG d'origine ! Évidemment, le résultat est plus gros, mais ça permet de servir du JPEG à ceux qui ne savent pas lire le JPEG XL.
[^] # Re: JPEG-XL
Posté par cosmocat . É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 . Évalué à 6.
Rappel: Une réponse à leur choix
https://cloudinary.com/blog/the-case-for-jpeg-xl
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) . É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 . Évalué à 10.
Si tu aimes bien les images:
# Avis sur HEIF
Posté par Funix (site web personnel, Mastodon) . Évalué à 4.
Ton avis sur HEIF me parait assez radical et infondé, outre Apple, il a été choisi également par Sony et Canon qui est un poids lourd dans la photographie numérique et nikon commence à s'y mettre aussi avec son nouveau Z8, les logiciels suivront Gimp et Darktable reconnaissent déjà HEIF.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Avis sur HEIF
Posté par FDF (site web personnel) . Évalué à 8.
Ton analyse semble pertinente, mais en effet, j'espère que ça ne s'imposera pas car le problème de licence va nous retomber dessus.
Il faudrait vraiment qu'il ai un avantage technique majeur, ce qui n'est pas exposé ici. Sinon, ça sent la tentative de domination du marché par les acteurs installés.
Je me trompe? J'espère.
[^] # Re: Avis sur HEIF
Posté par Funix (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 25 juin 2023 à 15:00.
Ce journal est bien trop simpliste pour se faire une réelle idée et n'est pas digne d'une dépêche
J'avais écrit il y a quelque temps un journal sur le format HEIF.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Avis sur HEIF
Posté par orfenor . É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 . É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) . Évalué à 10. Dernière modification le 26 juin 2023 à 10:20.
Infondé, et puis quoi encore ? Alors, voyons un peu les fondements en question.
HEIF est :
AVIF est :
JPEG XL est :
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) . É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) . É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 . É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) . É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 . É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) . É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) . Évalué à 9.
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) . É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 . É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) . Évalué à 4.
Ç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 . É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) . É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) . Évalué à 6.
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:
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.heicen 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
libheifet désactivaient entièrement notre plug-infile-heifdans 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
libheifqui ne contienne que les codecs de compression et décompression pour AVIF (puisque cette bibliothèque est aussi modulaire). Notre plug-infile-heiffaisant 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) . Évalué à 2.
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) . Évalué à 3.
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) . É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 (site web personnel, Mastodon) . Évalué à 1.
Ca, c'est 1% du marché. 80%, c'est le web et le web n'a pas envie de payer des licences. Le web, ce sont les navigateurs mais aussi les sites web qui te demandent d'importer une photo.
Au final si l'open-source s'est imposé presque partout dans l'informatique, il y a une raison: il pose moins de problèmes.
Et puis, ce n'est pas pour te déprimer mais il n'y a plus grand monde à avoir un appareil photo (Nokia ou autre). Alors Apple fera toujours sa sauce mais cela reste entre gens Apple.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Avis sur HEIF
Posté par Funix (site web personnel, Mastodon) . Évalué à 3.
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) . É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) . Évalué à 2.
j'ai passé l'âge d'écrire des lettres au père noël, j'y crois plus
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) . É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) . É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 . Évalué à 0. Dernière modification le 26 juillet 2023 à 21:52.
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 . Évalué à 5.
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) . Évalué à 3.
Pour compléter la comparaison : les fichiers raw ne sont pas des fichiers image. C’est un enregistrement des données sorties du capteur, non modifiées1. Il faut un traitement complexe plein de choix arbitraires pour transformer un raw en image.
Pour garder le parallèle musical, les raw c’est les fichiers master de la photo, les données brutes d’enregistrement sur lesquelles tu ne veux aucune compression destructive, mais qui ne servent à rien en soi, sans traitement.
Beaucoup de gens n’ont ni besoin ni utilité de ces données, ce qu’ils veulent, c’est juste le résultat final, prêt à l’emploi. Ça implique d’accepter les choix arbitraires susmentionnés qu’a fait l’appareil (smartphone ou « JPEG/HEIF du boiter ») sans retraitement ailleurs qu’à la marge, et très souvent ça fait le boulot. Ces fichiers pourraient être produits sans compression destructive (mais pas sans destruction, les données du capteurs ne pouvant pas être retrouvées suite aux traitements effectués pour les transformer en image), mais ça n’a pas grand intérêt.
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) . É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 . É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) . É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) . É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) . Évalué à 4.
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) . É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 . É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 . É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) . É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 thoasm . Évalué à 7.
Le bit est incompressible, mais on ne compresse jamais un bit, mais une séquence de bits.
(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) . É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 . Évalué à 1.
Ouais, sauf en informatique quantique. Et dans certains films aussi.
[^] # Re: Compression sans perte ou encodage ?
Posté par nud . É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 . É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) . Évalué à 8.
En PNG tu n'as pas obligatoirement :
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.
[^] # Re: PNG encore utile.
Posté par Yth (Mastodon) . Évalué à 3.
Ya même la palette 1-bit pour une icône en ombre chinoise : noir et transparent, j'ai un exemple en 171x171 qui fait 549 octets, imbattable ?
[^] # Re: PNG encore utile.
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
Pourquoi pas un svg pour les logos, favicon et icônes ? C'est tout à fait adapté pour ce type d'images et encore plus léger.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: PNG encore utile.
Posté par ted (site web personnel) . Évalué à 5. Dernière modification le 26 juin 2023 à 10:39.
Sur des images très petites je ne pense pas que le vectoriel soit pertinent. Il faut le convertir en pixels avant de l'afficher, et avec les filtres antialiasing ça ajoute du flou. Sans antialiasing on a des pixels qui peuvent ne pas être au bon endroit et qui font tache.
Avec une petite icône matricielle on peut faire du pixel art et avoir des images très lisibles malgré le faible nombre de pixels.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: PNG encore utile.
Posté par Dring . É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) . É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) . Évalué à 3.
Ah oui, effectivement, je viens de faire un test sur une icône que j'ai dessinée :
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) . É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) . É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) . É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) . É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 . É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) . É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) . É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 :
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) . Évalué à 2.
Correction effectuée
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: PNG encore utile.
Posté par orfenor . É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) . É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 :
[^] # Re: PNG encore utile.
Posté par nud . É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:
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:
[^] # Re: PNG encore utile.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
À refaire, j'ai dû me planter quelque part. :-)
[^] # Re: PNG encore utile.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Voilà, c'est refait. J'avais oublié de surtout ne mettre aucune métadonnée dans le PNG.
Donc, avec une image de 16×16 avec quelques traits de noir sur fond transparent :
Et pour comparaison, le même genre de dessin trivial (trois lignes et un polygone) en SVG optimisé par Inkscape :
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 . É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) . É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.
[^] # Re: PNG encore utile.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Allez, à mon tour.
Compression de 44 icônes en 64×64. Ce sont les icônes d'applications du thème hicolor :
pngnq, donc avec destruction : 172 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) . Évalué à 6.
Au temps pour moi, il y a bien un compresseur fourni avec libheif. Sur les icônes de 128×128 ça donne :
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) . Évalué à 3.
Ç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) . É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.
[^] # Re: PNG encore utile.
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Je ne sais pas comment ce SVG est optimisé, mais par exemple, le logo de Google tient dans un SVG de 305 octets, et en passant un peu de temps sur le sujet, des gens sont arrivés à le réduire à 146 octets:
https://clicktorelease.com/blog/svg-google-logo-in-305-bytes/
Et ça c'est pour le SVG. Comme ce n'est pas toujours suffisant, il existe des formats vectoriels conçus pour prendre très peu de place. Le format HVIF de Haiku est un exemple, et il y a aussi IconVG. Mais pour l'instant, pas d'utilisation possible dans les navigateurs web :(
[^] # Re: PNG encore utile.
Posté par cosmocat . É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 . É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) . É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) . É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 . É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) . Évalué à 2.
tu peux réessayer avec des logiciels plus actuels ;-) j'ai trouvé :
sur gitlab, je ne vois qu'un projet https://gitlab.com/explore/projects/topics/Fractal+compression
[^] # Re: Et la compression fractale ?
Posté par orfenor . É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) . Évalué à 2.
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) . É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 . É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 . É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) . É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 . Évalué à 1.
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) . Évalué à 4.
J'aimerais bien que tu en dises plus sur cette « complication »…
[^] # Re: Formats non destructifs indispensables
Posté par nud . É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 . É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 . É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 . É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 . É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) . Évalué à 7.
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 . Évalué à 1.
J'aurais pu préciser "Arts plastiques"
[^] # Re: Formats non destructifs indispensables
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9. Dernière modification le 26 juin 2023 à 17:41.
Ça ne prend toujours pas de majuscule. Certains travaillent dans l'informatique libre, dans les travaux publics ou dans la chirurgie reconstructrice sans revendiquer une majuscule.
[^] # Re: Formats non destructifs indispensables
Posté par Maderios . É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 . Évalué à 3.
Et, par curiosité intéressée, tu fais quoi ?
[^] # Re: Formats non destructifs indispensables
Posté par Maderios . É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 . Évalué à 4.
ça m'interresse encore plus !
on peut en voir qq part ?
[^] # Re: Formats non destructifs indispensables
Posté par Maderios . Évalué à -1.
Impossible, anonymat sur le Net, oblige…
[^] # Re: Formats non destructifs indispensables
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8.
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, 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 . É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:
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) . É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) . É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) . É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) . É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) . Évalué à 6.
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) . Évalué à 4.
TIFF permet de faire des fichiers multi-pages.
[^] # Re: Portable Document Format
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 26 juin 2023 à 17:56.
Et le PDF garde le texte en texte, donc lisible par les dispositifs d’assistance et copiable en texte. Et il peut être transformé en EPUB.
Un texte image, même sur plusieurs pages, reste de l’image donc pas lisible des dispositifs d’assistance, notamment.
Perso, j’ai tendance à plutôt dire que le PDF est un genre de « photocopie » numérique, mais en plus riche et toutes proportions gardées rapport à ce qui figure ci-dessus.
Cela dit, en informatique le terme « image » a aussi un autre sens qui serait plutôt synonyme de « clone » ou de copie identique que de dessin par exemple. En ce sens, le PDF est effectivement une « image » du document.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Portable Document Format
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Sauf que justement, dans un PDF on peut très bien stocker seulement des images matricielle. Ça a assez peu d'intérêt… sauf pour les numérisations en très haute définition de document en noir et blanc. Le format idéal pour ça, c'est le DjVu, mais peu de gens peuvent le lire. Le second format idéal, c'est JBIG2, mais à peu près personne ne peut le lire… sauf si c'est mis dans un document PDF !
[^] # Re: Portable Document Format
Posté par BAud (site web personnel) . Évalué à 6. Dernière modification le 26 juin 2023 à 18:51.
moui, bah ça c'est souvent dans le désordre :/
nombre de fois, j'ai tenté de copier le contenu :
bref, pour moi, PDF est un format d'impression, pas pour un stockage réversible permettant d'accéder facilement au contenu…
pdf2txts'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) . É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) . É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) . É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) . É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) . É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 . É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 . É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 . É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) . É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) . Évalué à 4.
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 . Évalué à 4. Dernière modification le 23 juillet 2023 à 17:57.
Hello :)
Pour les copies projections, oui, avec perte.
Pour les archives type IMF, c'est sans (réversible).
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) . É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) . É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) . Évalué à 3.
Le ou la gif ou jif ?
[^] # Re: la gif89a est vivante !
Posté par Tonton Th (site web personnel, Mastodon) . É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) . É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 . É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) . É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 . É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) . É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 . É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) . É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) . É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) . É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) . É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) . É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) . É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 . É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) . É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) . Évalué à 2.
Tu es tout pardonné !
[^] # Re: Format ouvert et spécifications ouvertes
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Je sais pas si tu fais beaucoup de développement, mais même s'il arrive bien entendu de s'inspirer de code existant, lire du code complexe pour le réimplémenter n'a rien d'une partie de plaisir et surtout n'a rien de simple.
Très souvent, dans un cas tel que de la prise en charge de format de fichier ou de protocole, il sera même bien plus simple de faire de l’ingénierie inverse directement sur des échantillons de fichiers existants que d'essayer de lire 5000 lignes de code existant.
Le coup du "Ça existe déjà dans le logiciel libre X, pourquoi vous reprenez pas juste le code?" est probablement l'une des déclarations les plus vaines et frustrantes qu'on lit régulièrement sur le web, de gens qui ne développent pas (ou peu).
Bien sûr, l'existence de code, ça aide. Mais lire du code complexe n'est absolument pas équivalent à une spec qui dira la même chose en un paragraphe de texte simple qu'un code qui fera des boucles, des renvois en fonctions, des
break, manipulera probablement des octets (on parle de données) et des bits (flags de bit, etc. typique dans les formats de fichiers), possiblement avec des optimisations de traitement super abscons et opaques qu'on doit relire 5 fois avant de comprendre ce que ça fait et dont on aura déjà oublié à moitié la logique le lendemain quand on relira le même code (et complètement une semaine après). Parce que dès qu'on se met à manipuler des octets et des bits, il y a toujours énormément de trucs super pas clairs pour permettre des optimisations en lecture-écriture (la différence entre un algorithme dit "naïf" qui est celui implémenté en premier car il paraît logique et qui est donc aussi simple à lire, et celui optimisé quand on se rend compte que son algo naïf est aussi super lent — genre 50 fois plus lent qu'un algo optimisé mais abscons — quand on doit traiter de vrais données du monde réel, donc des images super méga grosses).Et ça c'est sans parler du fait qu'on parle d'image et de couleur, donc avec en plus de la conversion de modèles de couleur, parfois des trucs bizarres dans la gestion des canaux, etc.
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 . Évalué à 2.
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) . Évalué à 3.
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 . É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) . É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.