Cette partie est généralement gérée par le conteneur (par exemple Matroska), il y a des experts en la matière pour gérer ton exemple.
Ah oui c’est vrai qu’avec matroska on peut aussi concaténer des pistes vidéos, et puis en intra-frame peut-être qu’on doit pouvoir avoir des parties déduplicables entre deux images clés identiques.
Pour info il y avait une tentative FLIF "inspiré" (au départ il prenait pas mal tout :) ) de FFV1 mais son auteur semble être allé du côté obscur de la force (chez JPEG pour travailler sur JPEG XL.
Oui je suis FLIF, enfin maintenant FUIF, avec attention puisque j’ai un intérêt pour les formats d’image en général et les formats d’image sans perte en général, que ce soit pour pour les besoins de ceux avec qui je travaille (archivage) ou pour mes propres besoins (photographie, jeu vidéo) qui apportent leur propres problématiques : archivage mais aussi versionnage (ce qui implique d’avoir accès aux anciennes versions aussi facilement que les versions actuelles), et les contraintes d’efficacité de (dé)compression en terme de fidélité, de temps et d’énergie. Un format comme le WebP lossless est intéressant comparé au PNG 8 bit (et il commence à être bien pris en charge), mais ça reste du 8 bit, et pour la photo, produire un WebP lossless 8-bit n’est pas sans perte en fait puisque ce n’est « sans-perte » qu’après avoir déjà perdu de la précision. Les appareils photos produisent souvent des fichiers permettant de travailler en 10, 12 ou 14-bit et les logiciels comme Darktable gèrent ça très bien, donc même un WebP 8-bit "sans-perte" perd beaucoup.
Ce qui me gène beaucoup avec le PNG c’est (mais ce n’est pas à toi que je vais l’apprendre =D) :
l’algorithme de compression semble n’avoir rien de spécifique aux images, une compression zlib dans un conteneur personnalisé (bref, pas mieux que zip) ;
la capacité à être plus efficace que zip repose sur la multitude de variantes du format PNG, avec divers formats fonctionnant mieux que d’autres selon chaque image ;
les outils produisant du PNG ne cherchent généralement pas à sélectionner quelle variante est la plus efficace pour une image donnée, d’ordinaire il faut utiliser un optimiseur après ça (ce qui suppose que le temps de la première compression PNG a été dépensé pour rien) ;
les outils lisant du PNG peuvent être mal testés étant donné que très peu d’outils produisent des PNG utilisant les formats efficaces ;
c’est lent à écrire et à lire ;
ça reste gros comparé à ce qu’on sait faire aujourd’hui, même en optimisant de manière insensée...
J’ai eu à débugger la prise en charge de PNG dans un logiciel et en me souvenant qu’IE6 ne gérait pas non-plus complètement le PNG j’ai commencé à ressentir de la compassion pour les développeurs d’Internet Explorer. :'(
C’est dommage que FLIF s’éloigne de FFV1 mais en même temps le fait qu’on puisse convertir du JPEG en FUIF sans ajouter de dégradation existante est très vendeur... Et c’est très alléchant de pouvoir ajouter une canal alpha à un JPG sans recompresser (avec perte) la partie RGB.
Par contre vu tous les cas d’usage que FUIF est capable de gérer, il va falloir une bibliothèque faisant beaucoup d’abstraction pour le commun des mortels... Par exemple pour ceux qui ne font que visualiser des images, une façon simple d’obtenir un équivalent RGBA 8-bit sans à voir à gérer soi-même les diverses variantes du format et les transformations éventuelles serait très pratique. Pour l’outil précité (NetRadiant) c’est tout ce dont j’aurai besoin, rgba = load(file);, peu importe si la précision est perdue ou si au contraire la précision est inutilement élevée.
Une problématique qui est peut-être nouvelle, c’est l‘efficacité à dédupliquer qui peut se révéler plus importante que l’efficacité à compresser. Un format .odt est un zip, et le format zip compresse chaque fichier indépendamment, ce qui est moins efficace qu’une archive « flat » qui compresserait l’ensemble de tous les fichiers concaténés, sauf que si on ne modifie qu’un seul fichier du zip, un logiciel de versionnage doit pouvoir dédupliquer tout ce qui n’a pas changé.
Faudra que j’en parle à Jehan tiens, si Gimp veut être dans le futur il faudra que les futurs .xcf visent la déduplication plutôt que la compression, en compressant chaque calque séparément par exemple, de manière à ce que modifier un seul calque ne fasse qu’un delta de la taille de calque dans un dépôt versionné. On peut même pousser le vice à compresser chaque canal séparément, car dans certains usages, les canaux RGBA peuvent en fait coder des données indépendantes, et on peut imaginer ne vouloir éditer que la rugosité d’un seul calque, et voir tout le reste dédupliqué dans le stockage du gestionnaire de version. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le poids du sans-perte.
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 9.
Ah oui c’est vrai qu’avec matroska on peut aussi concaténer des pistes vidéos, et puis en intra-frame peut-être qu’on doit pouvoir avoir des parties déduplicables entre deux images clés identiques.
Oui je suis FLIF, enfin maintenant FUIF, avec attention puisque j’ai un intérêt pour les formats d’image en général et les formats d’image sans perte en général, que ce soit pour pour les besoins de ceux avec qui je travaille (archivage) ou pour mes propres besoins (photographie, jeu vidéo) qui apportent leur propres problématiques : archivage mais aussi versionnage (ce qui implique d’avoir accès aux anciennes versions aussi facilement que les versions actuelles), et les contraintes d’efficacité de (dé)compression en terme de fidélité, de temps et d’énergie. Un format comme le WebP lossless est intéressant comparé au PNG 8 bit (et il commence à être bien pris en charge), mais ça reste du 8 bit, et pour la photo, produire un WebP lossless 8-bit n’est pas sans perte en fait puisque ce n’est « sans-perte » qu’après avoir déjà perdu de la précision. Les appareils photos produisent souvent des fichiers permettant de travailler en 10, 12 ou 14-bit et les logiciels comme Darktable gèrent ça très bien, donc même un WebP 8-bit "sans-perte" perd beaucoup.
Ce qui me gène beaucoup avec le PNG c’est (mais ce n’est pas à toi que je vais l’apprendre =D) :
J’ai eu à débugger la prise en charge de PNG dans un logiciel et en me souvenant qu’IE6 ne gérait pas non-plus complètement le PNG j’ai commencé à ressentir de la compassion pour les développeurs d’Internet Explorer. :'(
C’est dommage que FLIF s’éloigne de FFV1 mais en même temps le fait qu’on puisse convertir du JPEG en FUIF sans ajouter de dégradation existante est très vendeur... Et c’est très alléchant de pouvoir ajouter une canal alpha à un JPG sans recompresser (avec perte) la partie RGB.
Par contre vu tous les cas d’usage que FUIF est capable de gérer, il va falloir une bibliothèque faisant beaucoup d’abstraction pour le commun des mortels... Par exemple pour ceux qui ne font que visualiser des images, une façon simple d’obtenir un équivalent RGBA 8-bit sans à voir à gérer soi-même les diverses variantes du format et les transformations éventuelles serait très pratique. Pour l’outil précité (NetRadiant) c’est tout ce dont j’aurai besoin,
rgba = load(file);, peu importe si la précision est perdue ou si au contraire la précision est inutilement élevée.Une problématique qui est peut-être nouvelle, c’est l‘efficacité à dédupliquer qui peut se révéler plus importante que l’efficacité à compresser. Un format .odt est un zip, et le format zip compresse chaque fichier indépendamment, ce qui est moins efficace qu’une archive « flat » qui compresserait l’ensemble de tous les fichiers concaténés, sauf que si on ne modifie qu’un seul fichier du zip, un logiciel de versionnage doit pouvoir dédupliquer tout ce qui n’a pas changé.
Faudra que j’en parle à Jehan tiens, si Gimp veut être dans le futur il faudra que les futurs .xcf visent la déduplication plutôt que la compression, en compressant chaque calque séparément par exemple, de manière à ce que modifier un seul calque ne fasse qu’un delta de la taille de calque dans un dépôt versionné. On peut même pousser le vice à compresser chaque canal séparément, car dans certains usages, les canaux RGBA peuvent en fait coder des données indépendantes, et on peut imaginer ne vouloir éditer que la rugosité d’un seul calque, et voir tout le reste dédupliqué dans le stockage du gestionnaire de version. =)
ce commentaire est sous licence cc by 4 et précédentes