(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... )
Je ne prétend pas être un un bon programmeur, loin de là... J'avais jetter un coup d'oeil aux papiers que tu as publier sur le sujet, et.... ce sera pour plus tard...
Ma remarque sur la lenteur de GreycStoration n'était pas une critique, mais une constatation. D'un point de vue objectif, actuellement, vu les photos pour lesquelles j'en aurais besoin, je ne peut pas me permettre d'utiliser GreycStoration systématiquement.
Et je le regrette, même si ce n'est pas de ta faute, mais du à l'algo lui-même. De la même manière que je regrette qu'il pleuve les jours où je veut tondre la pelouse : on ne peut rien y faire, mais ça nous embette quand même ;-)
GreycStoration m'a permis quand même de récupérer des photos très bruitées ou NoiseNinja n'était pas suffisant, la seule chose c'est qu'il faut avoir un peu de temps devant soit et jouer avec les paramètres.
Après il faudrais peut-être que je change mon matos, mais j'ai pas trop les moyens pour le moment ;-)
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.
J'aime la philosophie des outils unix, et les utilisent beaucoup. Il y a quand même une différence, c'est qu'ils sont prévus pour être utilisés en flux, alors que dans ce cas ce sont des échanges.
Si l'on souhaite écrire un script pour gimp qui alterne les traitement classique de Gimp et ceux de G'MIC, il va y avoir de nombreux allez-retours entre les deux.
Mais dans tous les cas, c'est principalement une affaire de goûts. Je ne fait que donner mon point de vue.
(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).
Je ne te demande pas de le faire ;-) Je ne faisait que décrire mon rêve en tant qu'utilisateur. Dans tous les cas, je crois même que je préfère que tu continue de le faire comme maintenant, au moins je suis à peu près sûr qu'il va continuer à évoluer, pour mon plus grand plaisir.
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.
J'en suis beaucoup moins sûr que toi. Le passage à GEGL va permettre le traitement des photos 16bits dans Gimp (12bits dans mon cas) et donc sa prinipale limitation actuelle dans le dévellopement des fichiers RAW va être supprimée. Gimp 3.0 sera donc un très bon outils je pense pour ce genre de boulot, et au moins pour moi un plugins GreycStoration sera presque indispensable.
Écrire un node pour GEGL qui se contente d'appeler un programme externe est relativement simple, de même que la gestion des paramètres.
Donc, si personne ne le fais avant, il y a de fortes chance pour que moi je le fasse quand un Gimp basé sur Gegl sera utilisable. (pas la 2.6 qui, même si elle utilise Gegl, ne permet de manipuler les nodes dans l'interface)
[^] # Re: Merci
Posté par beagf . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Je ne prétend pas être un un bon programmeur, loin de là... J'avais jetter un coup d'oeil aux papiers que tu as publier sur le sujet, et.... ce sera pour plus tard...
Ma remarque sur la lenteur de GreycStoration n'était pas une critique, mais une constatation. D'un point de vue objectif, actuellement, vu les photos pour lesquelles j'en aurais besoin, je ne peut pas me permettre d'utiliser GreycStoration systématiquement.
Et je le regrette, même si ce n'est pas de ta faute, mais du à l'algo lui-même. De la même manière que je regrette qu'il pleuve les jours où je veut tondre la pelouse : on ne peut rien y faire, mais ça nous embette quand même ;-)
GreycStoration m'a permis quand même de récupérer des photos très bruitées ou NoiseNinja n'était pas suffisant, la seule chose c'est qu'il faut avoir un peu de temps devant soit et jouer avec les paramètres.
Après il faudrais peut-être que je change mon matos, mais j'ai pas trop les moyens pour le moment ;-)
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.
J'aime la philosophie des outils unix, et les utilisent beaucoup. Il y a quand même une différence, c'est qu'ils sont prévus pour être utilisés en flux, alors que dans ce cas ce sont des échanges.
Si l'on souhaite écrire un script pour gimp qui alterne les traitement classique de Gimp et ceux de G'MIC, il va y avoir de nombreux allez-retours entre les deux.
Mais dans tous les cas, c'est principalement une affaire de goûts. Je ne fait que donner mon point de vue.
(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).
Je ne te demande pas de le faire ;-) Je ne faisait que décrire mon rêve en tant qu'utilisateur. Dans tous les cas, je crois même que je préfère que tu continue de le faire comme maintenant, au moins je suis à peu près sûr qu'il va continuer à évoluer, pour mon plus grand plaisir.
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.
J'en suis beaucoup moins sûr que toi. Le passage à GEGL va permettre le traitement des photos 16bits dans Gimp (12bits dans mon cas) et donc sa prinipale limitation actuelle dans le dévellopement des fichiers RAW va être supprimée. Gimp 3.0 sera donc un très bon outils je pense pour ce genre de boulot, et au moins pour moi un plugins GreycStoration sera presque indispensable.
Écrire un node pour GEGL qui se contente d'appeler un programme externe est relativement simple, de même que la gestion des paramètres.
Donc, si personne ne le fais avant, il y a de fortes chance pour que moi je le fasse quand un Gimp basé sur Gegl sera utilisable. (pas la 2.6 qui, même si elle utilise Gegl, ne permet de manipuler les nodes dans l'interface)