Ton commentaire me fait quand même dire que la "propreté" (ou encore "beauté du code" comme certains disent..) c'est très subjectif...
(en passant, si GREYCstoration est lent sur des grosses images, c'est uniquement du à la complexité "théorique" de l'algorithme. Je crois pas que le code puisse être remis en cause de quelque manière que ce soit. Je te propose de reprogrammer le même algo, dans le même langage (C++) , je doute très fort que tu obtiennes un gain de performance significatif, aussi 'bon' programmeur que tu soit... )
Plus généralement, avoir un exécutable indépendant qui fait une tâche bien définie et qui peut être appelé à partir d'autres programmes (plug-in GIMP ou autre) avec des transferts de données par fichiers (ou par pipes), je trouve ça loin d'être sale (je crois pas être le seul, puisque c'est quand même l'une des bases de fonctionnement du système GNU/Linux). De plus :
(1) Ca a le gros avantage de réduire la difficulté du travail d'intération, donc la maintenance globale du logiciel 'appelant'. Chaque brique étant indépendante au maximum l'une de l'autre.
(2) Par conséquent, ca assure une plus grande pérenité au travail réalisé : si je m'amuse à interfacer G'MIC avec GEGL (qui est loin loin d'être un boulot trivial), et que dans 5 ans, GIMP se met au C++, et décide d'utiliser une autre lib (comme GIL, ou CImg , soyons fou :) ), mon utilisation de G'MIC sous GIMP est condamné, à moins de refaire un coûteux travail d'intégration avec une nouvelle lib. Au contraire, l'exécutable sera toujours fonctionnel lui (puisque conçu de manière 'self-contained' dès le départ).
L'expérience que nous avons tenté avec l'intégration de G'MIC dans QVOX de cette façon (G'MIC appelé par Q-VOX, avec transfert des données par pipes) me conforte dans cette idée. J'en viens presque à regretter que l'actuel plug-in de GREYCstoration n'ait pas été concu de cette manière dès le départ : Le passage à GIMP 3.0 risque d'être fatal au plug-in GREYCstoration, et je trouve ça bien dommage, car l'exécutable en ligne de commande à priori continuera d'être fonctionnel.
La "perte" de performance, dûe aux entrées sorties qu'il faut réaliser pour faire le pont entre GIMP et G'MIC (ou GREYCstoration) est minime, et de toute façon négligeable par rapport au temps d'exécution de l'algorithme lui-même.
[^] # Re: Merci
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 5.
(en passant, si GREYCstoration est lent sur des grosses images, c'est uniquement du à la complexité "théorique" de l'algorithme. Je crois pas que le code puisse être remis en cause de quelque manière que ce soit. Je te propose de reprogrammer le même algo, dans le même langage (C++) , je doute très fort que tu obtiennes un gain de performance significatif, aussi 'bon' programmeur que tu soit... )
Plus généralement, avoir un exécutable indépendant qui fait une tâche bien définie et qui peut être appelé à partir d'autres programmes (plug-in GIMP ou autre) avec des transferts de données par fichiers (ou par pipes), je trouve ça loin d'être sale (je crois pas être le seul, puisque c'est quand même l'une des bases de fonctionnement du système GNU/Linux). De plus :
(1) Ca a le gros avantage de réduire la difficulté du travail d'intération, donc la maintenance globale du logiciel 'appelant'. Chaque brique étant indépendante au maximum l'une de l'autre.
(2) Par conséquent, ca assure une plus grande pérenité au travail réalisé : si je m'amuse à interfacer G'MIC avec GEGL (qui est loin loin d'être un boulot trivial), et que dans 5 ans, GIMP se met au C++, et décide d'utiliser une autre lib (comme GIL, ou CImg , soyons fou :) ), mon utilisation de G'MIC sous GIMP est condamné, à moins de refaire un coûteux travail d'intégration avec une nouvelle lib. Au contraire, l'exécutable sera toujours fonctionnel lui (puisque conçu de manière 'self-contained' dès le départ).
L'expérience que nous avons tenté avec l'intégration de G'MIC dans QVOX de cette façon (G'MIC appelé par Q-VOX, avec transfert des données par pipes) me conforte dans cette idée. J'en viens presque à regretter que l'actuel plug-in de GREYCstoration n'ait pas été concu de cette manière dès le départ : Le passage à GIMP 3.0 risque d'être fatal au plug-in GREYCstoration, et je trouve ça bien dommage, car l'exécutable en ligne de commande à priori continuera d'être fonctionnel.
La "perte" de performance, dûe aux entrées sorties qu'il faut réaliser pour faire le pont entre GIMP et G'MIC (ou GREYCstoration) est minime, et de toute façon négligeable par rapport au temps d'exécution de l'algorithme lui-même.
David.