En réalité, il faut voir ça de manière un peu plus générique.
G'MIC n'a aucune notion de l'espace couleur du fichier que tu lui donnes en entrée, ni de celui que tu veux utiliser en réalité. Tu lui donnes une image couleur codée en RGB non linéaire, mais lui il s'en fiche un peu, il traite les canaux comme des canaux de données brutes, il voit juste qu'il y a 3 canaux dans le fichier que tu lui donnes. Pire encore, il n'a aucune raison même de croire que ce que tu lui donnes à manger est une image couleur, ca pourrait être aussi bien une image a 128 canaux correspondant à des longueurs d'ondes différentes (image satellite par exemple), lui, il va appliquer l'algorithme qu'on lui demande d'appliquer sans prendre de décisions derrière ton dos (et c'est heureux d'ailleurs !). Il ne va donc jamais prendre la décision tout seul d'appliquer un gamma automatiquement avant de redimensionner, puis de réappliquer le gamma inverse. Si quelqu'un utilises un PNG pour stocker des infos à 3 canaux ne correspondant pas à des couleurs, il a surement pas envie de voir un gamma s'appliquer automatiquement sur ses données quand il fait un redimensionnement ! Il risque de pas comprendre pourquoi il obtient un résultat qu'il n'attendait pas.
Peut-être que la plupart des logiciels de traitement d'images prennent ce genre de décision tout seul, mais à mon sens, c'est une erreur, *sauf* si ils ne se spécialisent que dans le traitement d'images couleurs évidemment (ce qui n'est pas du tout le cas de G'MIC, je le répète).
Si tu veux considérer des transformations spécifiques à la couleur, il faut soit le faire explicitement (ce que tu as fait), soit créer une fonction G'MIC qui va implémenter ton pipeline spécifique, si c'est toujours le même, en lui donnant un nom explicite pour bien faire voir que c'est un traitement propre à des images couleurs. Ici ca serait facile, ca s'écrirait en une ligne.
Pour ta question sur le 'resize', le mode d'interpolation par défaut est le '1' (c'est à dire, le plus proche voisin), ce qui dans ton cas explique le problème, même en appliquant le gamma, puisque le voisinage du pixel le plus proche n'est pas pris en compte. Si comme moi tu spécifie un mode d'interpolation '2' (c'est-à-dire les fenêtres coulissantes), qui prend en compte le voisinage, ca va mieux D'autres choix sont possibles et devraient donner des résultats satisfaisants dans ton cas.
Par ailleurs, je reviens sur ton premier post ou tu disais que tu obtenais une interpolation "fausse" (ce qui est aussi sous-entendu dans la page web que tu donnes en lien). Pour moi, une interpolation "fausse", ca veut rien dire. D'un point de vue mathématiques, l'interpolation te donne un résultat prédictif par l'algorithme qui est utilisé derrière. Dans la page que tu donnes, l'image présentée du Dalai-lama a été dégradée artificiellement pour que justement les techniques d'interpolations les plus classiques donnent un résultat visuellement mauvais (pour un être humain s'entend). Ca veut pas dire que ces interpolations sont plus fausses qu'autre chose ! Le fait d'appliquer tes gammas va résoudre ton problème pour cette image particulière, mais je peux très bien te générer une autre image synthétiquement à partir du même Daila-Lama, qui va donner un résultat d'interpolation pas satisfaisant (visuellement) avec ta méthode (il suffit d'appliquer le gamma inverse avant).
Pour conclure, je pense que je préfère largement avoir une idée de ce que fait mon algo sans qu'on me cache quelque chose (des transformations gamma que j'aurais pas souhaité par exemple). Je préfère dire explicitement à un programme (en l'occurence 'gmic') ce qu'il doit faire, plutôt qu'être obligé de comprendre et de réparer d'éventuels dégats qui se seraient produit par des actions que je n'aurais pas prévus.
Et justement, avec G'MIC, tu peux définir des propres pipelines pour traiter tes données, ca tombe bien.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par David Tschumperlé (site web personnel) . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 9.
G'MIC n'a aucune notion de l'espace couleur du fichier que tu lui donnes en entrée, ni de celui que tu veux utiliser en réalité. Tu lui donnes une image couleur codée en RGB non linéaire, mais lui il s'en fiche un peu, il traite les canaux comme des canaux de données brutes, il voit juste qu'il y a 3 canaux dans le fichier que tu lui donnes. Pire encore, il n'a aucune raison même de croire que ce que tu lui donnes à manger est une image couleur, ca pourrait être aussi bien une image a 128 canaux correspondant à des longueurs d'ondes différentes (image satellite par exemple), lui, il va appliquer l'algorithme qu'on lui demande d'appliquer sans prendre de décisions derrière ton dos (et c'est heureux d'ailleurs !). Il ne va donc jamais prendre la décision tout seul d'appliquer un gamma automatiquement avant de redimensionner, puis de réappliquer le gamma inverse. Si quelqu'un utilises un PNG pour stocker des infos à 3 canaux ne correspondant pas à des couleurs, il a surement pas envie de voir un gamma s'appliquer automatiquement sur ses données quand il fait un redimensionnement ! Il risque de pas comprendre pourquoi il obtient un résultat qu'il n'attendait pas.
Peut-être que la plupart des logiciels de traitement d'images prennent ce genre de décision tout seul, mais à mon sens, c'est une erreur, *sauf* si ils ne se spécialisent que dans le traitement d'images couleurs évidemment (ce qui n'est pas du tout le cas de G'MIC, je le répète).
Si tu veux considérer des transformations spécifiques à la couleur, il faut soit le faire explicitement (ce que tu as fait), soit créer une fonction G'MIC qui va implémenter ton pipeline spécifique, si c'est toujours le même, en lui donnant un nom explicite pour bien faire voir que c'est un traitement propre à des images couleurs. Ici ca serait facile, ca s'écrirait en une ligne.
Pour ta question sur le 'resize', le mode d'interpolation par défaut est le '1' (c'est à dire, le plus proche voisin), ce qui dans ton cas explique le problème, même en appliquant le gamma, puisque le voisinage du pixel le plus proche n'est pas pris en compte. Si comme moi tu spécifie un mode d'interpolation '2' (c'est-à-dire les fenêtres coulissantes), qui prend en compte le voisinage, ca va mieux D'autres choix sont possibles et devraient donner des résultats satisfaisants dans ton cas.
Par ailleurs, je reviens sur ton premier post ou tu disais que tu obtenais une interpolation "fausse" (ce qui est aussi sous-entendu dans la page web que tu donnes en lien). Pour moi, une interpolation "fausse", ca veut rien dire. D'un point de vue mathématiques, l'interpolation te donne un résultat prédictif par l'algorithme qui est utilisé derrière. Dans la page que tu donnes, l'image présentée du Dalai-lama a été dégradée artificiellement pour que justement les techniques d'interpolations les plus classiques donnent un résultat visuellement mauvais (pour un être humain s'entend). Ca veut pas dire que ces interpolations sont plus fausses qu'autre chose ! Le fait d'appliquer tes gammas va résoudre ton problème pour cette image particulière, mais je peux très bien te générer une autre image synthétiquement à partir du même Daila-Lama, qui va donner un résultat d'interpolation pas satisfaisant (visuellement) avec ta méthode (il suffit d'appliquer le gamma inverse avant).
Pour conclure, je pense que je préfère largement avoir une idée de ce que fait mon algo sans qu'on me cache quelque chose (des transformations gamma que j'aurais pas souhaité par exemple). Je préfère dire explicitement à un programme (en l'occurence 'gmic') ce qu'il doit faire, plutôt qu'être obligé de comprendre et de réparer d'éventuels dégats qui se seraient produit par des actions que je n'aurais pas prévus.
Et justement, avec G'MIC, tu peux définir des propres pipelines pour traiter tes données, ca tombe bien.