Je ne connaissais pas l'algorithme color2gray, donc je ne l'ai pas implémenté, mais ça ne me semble pas trop compliqué. Eventuellement, j'y jeterai un oeil, d'autant qu'ils proposent un pseudo-code Matlab sur leur page qui peut être éventuellement converti en nouvelle commande G'MIC. D'après les résultats que je vois, on peut avoir un type de résultats un peu équivalent en appliquant un algorithme de contraste local après le calcul de la luminance. Donc en G'MIC, tu peux essayer ceci (en ligne de commande) :
$ gmic lena.bmp -luminance -normalize_local 1
Ce n'est pas exactement pareil que color2gray (ça ne marchera pas sur les cas pathologiques présentés dans le papier, comme l'image du 45 pour les daltoniens par exemple), mais pour rehausser le contraste pour les images à mettre dans une publi, c'est pas mal.
En ce qui concerne l'organisation du code, c'est une question réccurente je peux te l'assurer :) Donc j'ai quand même bien réfléchi à la question. Pour ma part, je n'y vois que des avantages (sinon, je pense que j'aurais quand même pensé à le changer depuis le temps), notamment la facilité de maintenance du projet (dans ce contexte précis, où je suis quasiment seul développeur dessus). Toutes les fonctionnalités sont regroupées thématiquement au même endroit (1 fichier pour l'interpréteur, 1 fichier pour les algos de traitement, 1 fichier pour la définition des commandes et des filtres), et j'utilise facilement la recherche de texte sous emacs pour me déplacer à l'intérieur d'un gros fichier. Donc, au contraire, ça serait très pénible pour moi d'avoir 50 fichiers différents. Le fichier gmic_def.h est généré automatiquement, donc à la limite, ne pas le mettre dans le dépôt git serait une meilleure idée. Pour la bibliothèque CImg sous-jacente, la décomposer en plusieurs fichiers n'aurait à priori aucun intérêt "technique", autre que faire plaisir aux gens qui aiment avoir pleins de fichiers :). Ca peut être un peu long à expliquer, et j'ai déjà discuté de ça avec pas mal de personnes en essayant de donner des arguments étayés allant dans ce sens. Mais bon avec le temps, ce que j'ai aussi remarqué, c'est qu'en matière de code, chacun a souvent un avis bien tranché sur la question, et pense toujours connaître les "bonnes pratiques", même en ignorant totalement le contexte du projet et la structure du code. Comme l'auteur d'un logiciel est à priori le mieux renseigné sur la structure de son code, il me semble qu'il faut venir avec des arguments plus que solides pour le convaincre de changer. Je n'ai personnellement rien contre le changement (en tant que chargé de recherche, ça serait un comble), mais personne n'a encore réussi à me convaincre sur ce point là.
Le code de G'MIC est assez court (moins de 100kloc), en regard de ses fonctionnalités, donc refactoriser ce code ne serait pas forcément très long, ni très fastidieux. C'est juste que je ne vois pas de raisons valables de le faire pour ma part, et même pire, je pense que ça deviendrait plus long et plus difficile à maintenir. Si quelqu'un veut se lancer pour prouver le contraire, je l'encourage vivement bien entendu.
[^] # 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é à 10. Dernière modification le 17 avril 2015 à 11:58.
Je ne connaissais pas l'algorithme color2gray, donc je ne l'ai pas implémenté, mais ça ne me semble pas trop compliqué. Eventuellement, j'y jeterai un oeil, d'autant qu'ils proposent un pseudo-code Matlab sur leur page qui peut être éventuellement converti en nouvelle commande G'MIC. D'après les résultats que je vois, on peut avoir un type de résultats un peu équivalent en appliquant un algorithme de contraste local après le calcul de la luminance. Donc en G'MIC, tu peux essayer ceci (en ligne de commande) :
Ce n'est pas exactement pareil que color2gray (ça ne marchera pas sur les cas pathologiques présentés dans le papier, comme l'image du 45 pour les daltoniens par exemple), mais pour rehausser le contraste pour les images à mettre dans une publi, c'est pas mal.
En ce qui concerne l'organisation du code, c'est une question réccurente je peux te l'assurer :) Donc j'ai quand même bien réfléchi à la question. Pour ma part, je n'y vois que des avantages (sinon, je pense que j'aurais quand même pensé à le changer depuis le temps), notamment la facilité de maintenance du projet (dans ce contexte précis, où je suis quasiment seul développeur dessus). Toutes les fonctionnalités sont regroupées thématiquement au même endroit (1 fichier pour l'interpréteur, 1 fichier pour les algos de traitement, 1 fichier pour la définition des commandes et des filtres), et j'utilise facilement la recherche de texte sous emacs pour me déplacer à l'intérieur d'un gros fichier. Donc, au contraire, ça serait très pénible pour moi d'avoir 50 fichiers différents. Le fichier gmic_def.h est généré automatiquement, donc à la limite, ne pas le mettre dans le dépôt git serait une meilleure idée. Pour la bibliothèque CImg sous-jacente, la décomposer en plusieurs fichiers n'aurait à priori aucun intérêt "technique", autre que faire plaisir aux gens qui aiment avoir pleins de fichiers :). Ca peut être un peu long à expliquer, et j'ai déjà discuté de ça avec pas mal de personnes en essayant de donner des arguments étayés allant dans ce sens. Mais bon avec le temps, ce que j'ai aussi remarqué, c'est qu'en matière de code, chacun a souvent un avis bien tranché sur la question, et pense toujours connaître les "bonnes pratiques", même en ignorant totalement le contexte du projet et la structure du code. Comme l'auteur d'un logiciel est à priori le mieux renseigné sur la structure de son code, il me semble qu'il faut venir avec des arguments plus que solides pour le convaincre de changer. Je n'ai personnellement rien contre le changement (en tant que chargé de recherche, ça serait un comble), mais personne n'a encore réussi à me convaincre sur ce point là.
Le code de G'MIC est assez court (moins de 100kloc), en regard de ses fonctionnalités, donc refactoriser ce code ne serait pas forcément très long, ni très fastidieux. C'est juste que je ne vois pas de raisons valables de le faire pour ma part, et même pire, je pense que ça deviendrait plus long et plus difficile à maintenir. Si quelqu'un veut se lancer pour prouver le contraire, je l'encourage vivement bien entendu.