• [^] # Re: 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é à 7.

    Merci pour la commande. Juste pour le fun j'ai essayé avec une des images en exemple dans le paper, une qui correspond aux diagrammes que j'ai à imprimer de temps en temps.

    input
    output

    Malheureusement les couleurs sont dures à différencier en comparaison de ce que l'algorithme en question dit offrir:

    paper

    Toutefois merci pour l'aide, et si un jour cet algorithme est porté dans GMIC je me réjouirai de l'utiliser!

    Oui j'ai bien imaginé que la question avait déjà du être posée ;-) Il y a effectivement autant de façons de voir les choses que de développeurs. En étant le développeur principal, c'est sûrement ce qui te conviens le mieux et qui te permet de travailler le plus vite, et c'est très bien ainsi.

    Je disais ça plutôt d'un point de vue d'un personne externe, telle que le verrai un éventuel développeur intéressé à contribuer. Voilà quelques réflexions en vrac (en pensant bien que je ne connais pas du tout le code), à utiliser si cela peut-être utile:

    • Il m'a déjà fallu 20 min avec une bonne connexion internet et un bon ordinateur pour récupérer les sources. Bien que cela ne doive être fait qu'une seule fois, je n'ai pas eu la patience d'attendre que ça se termine la toute première fois que j'ai voulu y accéder, j'ai ctrl+c au milieu.
     $ git clone http://git.code.sf.net/p/gmic/source gmic
 [...]
 git clone http://git.code.sf.net/p/gmic/source gmic 15.81s user 3.66s system 1% cpu 20:00.48 total
    • En ouvrant le dossier src après cela, on se retrouve avec 4 énormes fichiers contenant entre 10'000 et 50'000 lignes. Ça ne donne pas beaucoup envie d'entrer dans le code.
     50782 CImg.h
 484 Makefile
 13789 gmic.cpp
 378 gmic.h
 27820 gmic_def.gmic
 41275 gmic_def.h
 3826 gmic_gimp.cpp
 87 gmic_in_script.scm
 139 gmic_use_lib.cpp
 138580 total
    • Les gens n'aiment pas spécialement avoir pleins de fichiers pour le principe, mais parce que cela permet d'avoir une carte mentale de ce qui se passe dans le code. Un exemple (totalement hypothétique) serait un dossier io/ avec tous les code gérant la lecture/écriture des images. Cela permettrait de savoir que si on veut ajouter du support pour un nouveau type d'image, c'est là-dedans que cela se passe. En entrant dans ce dossier, il y aurait le support d'un format d'image par fichier. Du coup le développeur n'aurait qu'à copier/coller un de ces fichiers et peut directement commencer à l'adapter au nouveau format de fichier. À l'inverse avec 4 gros fichiers, on ne sait pas ou chercher, comment s'appellent les méthodes, quelles méthodes doivent être fournies pour gérer un nouveau format d'image, etc. Par exemple dans un projet qui a une structure comme ceci:
    .
├── commands
│  ├── cmd_debug.ml
│  ├── cmd_init.ml
│  ├── cmd_status.ml
│  ├── cmd_version.ml
│  ├── command.ml
├── core
│  ├── config.ml
│  ├── utils.ml
│  ├── workspace.ml
├── display
│  ├── ansi.ml
│  ├── display.ml
│  ├── render.ml
│  └── symbols.ml
├── main.ml
└── version.ml

    On peut tout de suite voir quelle partie est dédiée à l'affichage, ou se trouve la configuration, quelles sont les différentes commandes, quel est le point d'entrée du programme, etc. Si a la place il y avait 2 ou 3 gros fichiers cela aurait été beaucoup plus difficile à comprendre qu'est ce qui se passe et où.

    Pour résumer: le découpage du code ralenti un peu les gens qui connaissent le code, mais permet aux gens qui ne le connaissent pas d'y entrer plus facilement. Au final c'est le choix du développeur principal que de préférer la rapidité de développement ou l'accessibilité du code.

    • git ne stockant pas les différences entre les versions des fichiers, mais bien le contenu des fichiers eux-mêmes à chaque commit, la taille des fichiers en question fait qu'une modification d'une seule ligne dans CImg.h pour un commit rajoute actuellement 472K au repository. Le découpage en plusieurs fichiers réduirait ce problème, qui est d'ailleurs la cause de la lenteur pour cloner le projet.
     $ echo "added" >> src/CImg.h
 $ git add src/CImg.h
 $ git hash-object src/CImg.h
 f62155609eb83c11ecfcb05107f079e914c62ff9
 $ du -h .git/objects/f6/2155609eb83c11ecfcb05107f079e914c62ff9
 472K .git/objects/f6/2155609eb83c11ecfcb05107f079e914c62ff9

    Voilà mes 2 centimes, en espérant que cela puisse être utile. Mais je tiens à noter que malgré ces quelques remarques, je suis impressionné par le rythme de développement de GMIC, comme quoi tout ça n'est pas si important!