les greffons PNG et TIFF ont dorénavant pour comportement par défaut de ne pas enregistrer la valeur des couleurs lorsqu’un canal alpha est présent et a pour valeur 0, ce changement fait suite aux problèmes de fuite de données lorsqu’on se contente de découper des morceaux d’image pour en cacher le contenu en y laissant de la transparence ;
Où se trouve l’option, dans la fenêtre d’export ? Il me semble en effet impératif que la valeur de cette option soit très facilement basculable à l’export.
J’ai un avis mitigé sur le fait que ce comportement soit activé par défaut. Je comprends parfaitement la problématique de fuites de données.
Je me souviens d’une étude dont la source de donnée avait été publiée sous forme de google doc, et tous les noms des milliers de personnes sondées avaient été « anonymisées » avec une couleur de fond noir et une couleur de texte noir, une simple sélection ou un simple copier-coller dans un bloc note révélait les noms des sondés... 🤦
De l’autre, il existe de réelles situations où il peut y avoir des données RGB à conserver dans un pixel avec un canal alpha complètement transparent.
1. Cas rencontré de données RGB à ne pas détruire (canal alpha erroné)
Par exemple avec le projet Unvanquished, j’ai rencontré avec de vieilles cartes de Tremulous une skybox qui apparaissait comme entièrement transparente dans les miniatures de l’explorateur de fichier nautilus ou dans un éditeur d’image, mais apparaissait comme correctement opaque et coloré dans le jeu. Les faces de la skybox était des images en TGA, mais la conversion en PNG conservait le comportement étonnant. J’avais découvert que tout simplement le canal alpha était à zéro mais que le rendu de skybox dans le jeu n’utilise pas le canal alpha (ce qui fait sens puisqu’il s’agit de couvrir le « vide » du fond de l’écran et qu’il n’y a par définition derrière la skybox que du vide, donc des valeurs indéterminées. Le canal alpha était donc simplement une donnée inutile qui ne codaient rien.
Un utilisateur qui convertirait naïvement les textures en ouvrant le TGA dans GIMP et exporterait en PNG détruirait les données.
La bonne chose à faire pour celui qui manipule de telles images serait de supprimer le canal alpha erroné, mais il est dangereux de supprimer les données en faisant une simple conversion de format, ce qui peut arriver avant que l’utilisateur ne découvre que le canal alpha est erroné.
Dans mon cas je me suis rendu compte du problème bien après avoir converti les images en PNG.
2. Données stockées dans des canaux RGBA qui ne sont pas vraiment des images (le canal alpha ne code pas la transparence)
Les images au format PNG et autres formats ne servent pas nécessairement à stocker les couleurs et la transparence d’un objet sur lequel la texture est appliquée. Il est courant par exemple de stocker les coordonnées XYZ d’une carte normale dans les canaux RGB, et l’élévation d’un champs de hauteur dans le canal Alpha.
Il est par exemple tout à fait légitime de stocker une carte normale plate avec une hauteur nulle (une profondeur maximale). Avec des valeurs dans l’ensemble [0.0, 1.0], une carte normale plate est codée comme (0.0, 0.0, 0.5) et une profondeur maximale est codée [0.0]. Dans le cas d’un fichier PNG stockant une carte normale et un champ de hauteur, dans le cas d’un canal alpha entièrement nulle, la destruction des canaux RGB doit produire des pixels de (0.0, 0.0, 0.5), pas de (0.0, 0.0, 0.0). Cet exemple de carte normale plate avec une profondeur maximale ne ressemble pas vraiment à un cas réel, mais c’est l’exemple le plus simple à décrire pour aborder le sujet. De réels cas avec tout un panachage de valeurs et quelques pixels avec un canal alpha à zéro est tout à fait réaliste.
Aussi, il existe des tas d’autres combinaisons de stockage de textures dans les canaux. Par exemple le moteur Unity recommande une valeur « smoothness » dans les canaux alpha des textures spéculaires ou métalliques. Dans ces cas on ne peut pas se baser sur la valeur du canal alpha d’un pixel pour détruire les données des autres canaux.
De manière générale, c’est une très mauvaise idée de détruire les données RGB en se basant sur le canal alpha pour tout ce qui ne code pas la couleur et la transparence d’une texture.
Il est tout à fait légitime de manipuler et d’éditer de telles « images » dans un éditeur comme GIMP.
Pour référence, l’outil d’optimisation de compression PNG oxipng propose l’option --alpha pour détruire les canaux RGB invisibles en cas de transparence complète pour gagner de la place, mais cette option n’est pas active par défaut, et heureusement ! Il est tout à fait possible de coder du « noir » (0, transparence complète) dans un canal alpha pour coder autre chose que de la transparence.
3. Il est possible de coder de la transparence mais de la faire varier ensuite
Il est tout à fait rationnel d’imaginer un logiciel (comme un jeu), qui lirait des composants RGB dans les composants RGB et un canal alpha dans le canal alpha, mais se garderait le droit de modifier le canal alpha pour réaliser certains effets. Par exemple on peut imaginer une image qui doit être pleinement transparente tant qu’aucun effet n’est utilisé, il ferait donc sens de mettre un canal alpha entièrement transparent dans ce cas, car ce serait la valeur par défaut. Il est impératif dans ce genre de situation que le canal RGB ne soit pas détruit.
4. Cas spécifiques de codage exotique
Il y a aussi le cas particulier où les canaux RGB ne sont pas stockés dans les canaux RGB pour produire une compression plus efficace avec des formats qui n’ont pas le même algorithme de compression selon les canaux (ce qui est vrai de PNG en fait) ou qui n’ont pas le même nombre de bit pour coder chaque composant, et dans certains cas, il est courant dans l’industrie de stocker les canaux RGB dans une autre disposition de canaux arbitraires. Par exemple il est courant pour une carte normale (qui n’aurait pas de donnée d’élévation dans le canal alpha) de ne pas stocker les coordonnées XYZ dans RGB mais X dans A, Y dans G, et de reconstruire Z par un calcul. Pour être honnête je mets ce cas en dernier parce que je doute beaucoup que des utilisateurs rencontrent ce problème avec GIMP.
En général ce genre d’optimisation se fait avec des format d’images spécifiques (DDS, CRN...), mais comme le PNG ne stocke pas le canal Alpha de la même manière que les canaux RGB, il n’est pas absurde de penser que des hacks de ce type puissent être utilisé avec le PNG. Il n’est pas absurde que des gens utilisent le format PNG comme format intermédiaire, même si je pense sincèrement qu’à peu près tout le monde utilise des outils qui échangent les canaux au moment de convertir un format comme le PNG vers le format final, sans stocker le fichier intermédiaire pour édition. Mais je ne peux pas garantir à 100% que ça n’arrive jamais nulle part.
Question probabilité que ces cas ce produisent, les cas 3. et 4. relèvent plus de l’expérience de pensée, j’ai déjà rencontré le cas 1. pour de vrai même si je reconnais que c’est exceptionnel, et pour le cas 2. ça peut concerner des milliers d’artistes et développeurs.
ce commentaire est sous licence cc by 4 et précédentes
# Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.20 : à votre santé !. Évalué à 10. Dernière modification le 22 juin 2020 à 01:36.
Où se trouve l’option, dans la fenêtre d’export ? Il me semble en effet impératif que la valeur de cette option soit très facilement basculable à l’export.
J’ai un avis mitigé sur le fait que ce comportement soit activé par défaut. Je comprends parfaitement la problématique de fuites de données.
Je me souviens d’une étude dont la source de donnée avait été publiée sous forme de google doc, et tous les noms des milliers de personnes sondées avaient été « anonymisées » avec une couleur de fond noir et une couleur de texte noir, une simple sélection ou un simple copier-coller dans un bloc note révélait les noms des sondés... 🤦
De l’autre, il existe de réelles situations où il peut y avoir des données RGB à conserver dans un pixel avec un canal alpha complètement transparent.
1. Cas rencontré de données RGB à ne pas détruire (canal alpha erroné)
Par exemple avec le projet Unvanquished, j’ai rencontré avec de vieilles cartes de Tremulous une skybox qui apparaissait comme entièrement transparente dans les miniatures de l’explorateur de fichier nautilus ou dans un éditeur d’image, mais apparaissait comme correctement opaque et coloré dans le jeu. Les faces de la skybox était des images en TGA, mais la conversion en PNG conservait le comportement étonnant. J’avais découvert que tout simplement le canal alpha était à zéro mais que le rendu de skybox dans le jeu n’utilise pas le canal alpha (ce qui fait sens puisqu’il s’agit de couvrir le « vide » du fond de l’écran et qu’il n’y a par définition derrière la skybox que du vide, donc des valeurs indéterminées. Le canal alpha était donc simplement une donnée inutile qui ne codaient rien.
Un utilisateur qui convertirait naïvement les textures en ouvrant le TGA dans GIMP et exporterait en PNG détruirait les données.
La bonne chose à faire pour celui qui manipule de telles images serait de supprimer le canal alpha erroné, mais il est dangereux de supprimer les données en faisant une simple conversion de format, ce qui peut arriver avant que l’utilisateur ne découvre que le canal alpha est erroné.
Dans mon cas je me suis rendu compte du problème bien après avoir converti les images en PNG.
2. Données stockées dans des canaux RGBA qui ne sont pas vraiment des images (le canal alpha ne code pas la transparence)
Les images au format PNG et autres formats ne servent pas nécessairement à stocker les couleurs et la transparence d’un objet sur lequel la texture est appliquée. Il est courant par exemple de stocker les coordonnées XYZ d’une carte normale dans les canaux RGB, et l’élévation d’un champs de hauteur dans le canal Alpha.
Il est par exemple tout à fait légitime de stocker une carte normale plate avec une hauteur nulle (une profondeur maximale). Avec des valeurs dans l’ensemble
[0.0, 1.0], une carte normale plate est codée comme(0.0, 0.0, 0.5)et une profondeur maximale est codée[0.0]. Dans le cas d’un fichier PNG stockant une carte normale et un champ de hauteur, dans le cas d’un canal alpha entièrement nulle, la destruction des canaux RGB doit produire des pixels de(0.0, 0.0, 0.5), pas de(0.0, 0.0, 0.0). Cet exemple de carte normale plate avec une profondeur maximale ne ressemble pas vraiment à un cas réel, mais c’est l’exemple le plus simple à décrire pour aborder le sujet. De réels cas avec tout un panachage de valeurs et quelques pixels avec un canal alpha à zéro est tout à fait réaliste.Aussi, il existe des tas d’autres combinaisons de stockage de textures dans les canaux. Par exemple le moteur Unity recommande une valeur « smoothness » dans les canaux alpha des textures spéculaires ou métalliques. Dans ces cas on ne peut pas se baser sur la valeur du canal alpha d’un pixel pour détruire les données des autres canaux.
De manière générale, c’est une très mauvaise idée de détruire les données RGB en se basant sur le canal alpha pour tout ce qui ne code pas la couleur et la transparence d’une texture.
Il est tout à fait légitime de manipuler et d’éditer de telles « images » dans un éditeur comme GIMP.
Pour référence, l’outil d’optimisation de compression PNG oxipng propose l’option
--alphapour détruire les canaux RGB invisibles en cas de transparence complète pour gagner de la place, mais cette option n’est pas active par défaut, et heureusement ! Il est tout à fait possible de coder du « noir » (0, transparence complète) dans un canal alpha pour coder autre chose que de la transparence.3. Il est possible de coder de la transparence mais de la faire varier ensuite
Il est tout à fait rationnel d’imaginer un logiciel (comme un jeu), qui lirait des composants RGB dans les composants RGB et un canal alpha dans le canal alpha, mais se garderait le droit de modifier le canal alpha pour réaliser certains effets. Par exemple on peut imaginer une image qui doit être pleinement transparente tant qu’aucun effet n’est utilisé, il ferait donc sens de mettre un canal alpha entièrement transparent dans ce cas, car ce serait la valeur par défaut. Il est impératif dans ce genre de situation que le canal RGB ne soit pas détruit.
4. Cas spécifiques de codage exotique
Il y a aussi le cas particulier où les canaux RGB ne sont pas stockés dans les canaux RGB pour produire une compression plus efficace avec des formats qui n’ont pas le même algorithme de compression selon les canaux (ce qui est vrai de PNG en fait) ou qui n’ont pas le même nombre de bit pour coder chaque composant, et dans certains cas, il est courant dans l’industrie de stocker les canaux RGB dans une autre disposition de canaux arbitraires. Par exemple il est courant pour une carte normale (qui n’aurait pas de donnée d’élévation dans le canal alpha) de ne pas stocker les coordonnées XYZ dans RGB mais X dans A, Y dans G, et de reconstruire Z par un calcul. Pour être honnête je mets ce cas en dernier parce que je doute beaucoup que des utilisateurs rencontrent ce problème avec GIMP.
En général ce genre d’optimisation se fait avec des format d’images spécifiques (DDS, CRN...), mais comme le PNG ne stocke pas le canal Alpha de la même manière que les canaux RGB, il n’est pas absurde de penser que des hacks de ce type puissent être utilisé avec le PNG. Il n’est pas absurde que des gens utilisent le format PNG comme format intermédiaire, même si je pense sincèrement qu’à peu près tout le monde utilise des outils qui échangent les canaux au moment de convertir un format comme le PNG vers le format final, sans stocker le fichier intermédiaire pour édition. Mais je ne peux pas garantir à 100% que ça n’arrive jamais nulle part.
Question probabilité que ces cas ce produisent, les cas 3. et 4. relèvent plus de l’expérience de pensée, j’ai déjà rencontré le cas 1. pour de vrai même si je reconnais que c’est exceptionnel, et pour le cas 2. ça peut concerner des milliers d’artistes et développeurs.
ce commentaire est sous licence cc by 4 et précédentes