Pour le genre d'images (synthétiques) que tu utilises, tu peux en général facilement trouver une façon de calculer le passage couleur -> scalaire avec une fonction plus adaptée à la visualisation que tu recherches. Sur l'image que tu donnes par exemple, au lieu de prendre la luminance, tu prends la Value de l'espace HSV (correspondant au max des valeurs sur RGB), et ça donne quelque chose qui m'a l'air correct, peut-être même plus naturel que ce que propose l'algo color2gray :
$ gmic input.jpg -split c -max -output rgbmax.png
rgbmax.png
Pour le code, encore une fois tout est question de personnalité de celui qui relit. J'ai moi-même lu pas mal de codes d'autres projets (des bibliothèques de traitement d'image principalement), et je préfère toujours aborder un projet avec peu de fichiers, à priori, je me dis que ça va être plus simple de s'y retrouver et je vais moins devoir chercher dans pleins de fichiers. Si je cherche une fonctionnalité précise, de toute façon, j'ai au moins un mot-clé que je peux utiliser pour chercher dans le fichier (au mieux, le nom de l'algorithme qui va apparaitre dans les commentaires associé au code, ou au pire, un nom de fonction d'une dépendence qui va être forcément utilisé à l'endroit où je cherche, genre appel X11).
Et dans un monde idéal, tes dizaines / centaines de fichiers devraient tous avoir un nom cohérent et une localisation cohérente, mais en vrai, comme tous les projets évoluent en dehors de l'imagination initiale de l'auteur, ça peut souvent finir rangé n'importe comment. Dire que beaucoup de fichiers facilite la lecture du code est pas quelque chose de généralisable (en tout cas, pour moi ça marche pas, je dois pas être le seul). Il m'est arrivé assez souvent de revenir à un bon vieux grep -R pour chercher une fonctionnalité précise dans des projets avec des foultitudes de fichiers. J'aurais honnêtement préféré faire un CTRL+S sous Emacs dans un seul gros fichier :)
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 7. Dernière modification le 17 avril 2015 à 15:11.
Pour le genre d'images (synthétiques) que tu utilises, tu peux en général facilement trouver une façon de calculer le passage couleur -> scalaire avec une fonction plus adaptée à la visualisation que tu recherches. Sur l'image que tu donnes par exemple, au lieu de prendre la luminance, tu prends la Value de l'espace HSV (correspondant au max des valeurs sur RGB), et ça donne quelque chose qui m'a l'air correct, peut-être même plus naturel que ce que propose l'algo color2gray :
rgbmax.png
Pour le code, encore une fois tout est question de personnalité de celui qui relit. J'ai moi-même lu pas mal de codes d'autres projets (des bibliothèques de traitement d'image principalement), et je préfère toujours aborder un projet avec peu de fichiers, à priori, je me dis que ça va être plus simple de s'y retrouver et je vais moins devoir chercher dans pleins de fichiers. Si je cherche une fonctionnalité précise, de toute façon, j'ai au moins un mot-clé que je peux utiliser pour chercher dans le fichier (au mieux, le nom de l'algorithme qui va apparaitre dans les commentaires associé au code, ou au pire, un nom de fonction d'une dépendence qui va être forcément utilisé à l'endroit où je cherche, genre appel X11).
Et dans un monde idéal, tes dizaines / centaines de fichiers devraient tous avoir un nom cohérent et une localisation cohérente, mais en vrai, comme tous les projets évoluent en dehors de l'imagination initiale de l'auteur, ça peut souvent finir rangé n'importe comment. Dire que beaucoup de fichiers facilite la lecture du code est pas quelque chose de généralisable (en tout cas, pour moi ça marche pas, je dois pas être le seul). Il m'est arrivé assez souvent de revenir à un bon vieux
grep -Rpour chercher une fonctionnalité précise dans des projets avec des foultitudes de fichiers. J'aurais honnêtement préféré faire un CTRL+S sous Emacs dans un seul gros fichier :)