• # color2gray et organisation du code

    Posté par . 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é à 5.

    Tout d'abord merci pour ce magnifique outil. J'ai déjà eu l'occasion de l'utiliser à bien des reprises, et certaines fonctionnalités telles que le patch-based inpainting lui sont uniques dans le monde du libre!

    Récemment je cherchais un outil pour transformer une image couleur en niveau de gris, d'une manière à préserver le contraste. C'était pour insérer cette image dans un document à imprimer en niveau de gris, de manière à ce que les graphiques restent lisibles. En gros une implémentation de color2gray telle que présentée dans ce paper. Je n'ai pas trouvé de fonctionnalité s'y rapprochant dans GMIC, l'aurais-je loupée? Et si non est-t'il déjà prévu d'implémenter une fonctionnalité du style dans le futur?

    Une question que je me pose en toute modestie et la raison l'organisation du code en 3 gigantesques fichiers? Je me la suis posée en cherchant si il y avait des occurrences de "decolorization" ou de "color2gray" (en rapport avec ma question précédente). Ne venant pas du monde du C/C++ je ne sais pas si il y a des raisons de performances ou autres à ce choix? J'y vois surtout des inconvénients, tels que la taille du repository git qui doit enregistrer un nouveau blob de 1.12M à chaque commit modifiant le fichiers gmic_def.h, ou encore la difficulté à entrer dans le code avec des fichiers de plus de 27'00 et 50'000 lignes. N'y a t'il pas moyen d'organiser la librairie dans différents dossiers/fichiers tout en les compilant en une seule entité? Ou est-ce devenu trop compliqué de le faire à ce point?