Dans le cas de GREYCstoration, c'est parfaitement adapté car le temps de calcul est vraiment long par rapport au temps du transfert et du fork.
Pour G'MIC, à mon avis, c'est complètement différent car la majorité des fonctions qu'il propose sont très rapides sur les images gérées par Gimp. J'ai pas testé sur des images volumétrique par exemple, mais c'est un peu hors de propos pour Gimp.
Ce qui peut rendre les traitement long, c'est l'utilisation de longue macro qui demandent à G'MIC d'appliquer de nombreux éffets les uns à la suite des autres.
En poussant la philosophie des pipes à font, G'MIC aurrait été codé sous la forme de dizaines de tout petit programmes applicant un seul filtre, et on les enchainerais avec des pipes.
Tu aurrait par exemple un programme gmic_noise, un gmic_sqrt... Le problème c'est que toutes ces opérations sont très rapides et au final le coût d'un fork plus du transfert de données serait très largement superieur au coût du vrai traitement.
C'est, à mon avis, une des raisons qui fait que G'MIC est un programme unique. Il est capable de faire plein d'opérations rapides et de les enchainées tout seul sans pipe. Mais il peut aussi être piper avec d'autres programmes pour faire ce qu'il ne sait pas faire.
[^] # 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.
Pour G'MIC, à mon avis, c'est complètement différent car la majorité des fonctions qu'il propose sont très rapides sur les images gérées par Gimp. J'ai pas testé sur des images volumétrique par exemple, mais c'est un peu hors de propos pour Gimp.
Ce qui peut rendre les traitement long, c'est l'utilisation de longue macro qui demandent à G'MIC d'appliquer de nombreux éffets les uns à la suite des autres.
En poussant la philosophie des pipes à font, G'MIC aurrait été codé sous la forme de dizaines de tout petit programmes applicant un seul filtre, et on les enchainerais avec des pipes.
Tu aurrait par exemple un programme gmic_noise, un gmic_sqrt... Le problème c'est que toutes ces opérations sont très rapides et au final le coût d'un fork plus du transfert de données serait très largement superieur au coût du vrai traitement.
C'est, à mon avis, une des raisons qui fait que G'MIC est un programme unique. Il est capable de faire plein d'opérations rapides et de les enchainées tout seul sans pipe. Mais il peut aussi être piper avec d'autres programmes pour faire ce qu'il ne sait pas faire.