Les pipes sont un outils fantastique, mais pas pour tout.
Typiquement, lorsque un problème peut être diviser en plusieurs petites tâches à appliquer en séquence sur les données et que ces données sont traîtées en flux, c'est génial.
En plus, vu la quantité de tels outils déjà disponible, le plus souvent ça économise un max de temps, et sur une machine multi-processeur ça te donne un parallélisme gratuit. Les pipes ont beaucoup d'avantage pour traîter ce genre de données.
Mais dans le cas ou tu travaille sur toutes les données d'un coup, donc en gros : tout charger en mémoire, faire le calcul et sortir tout le résultat d'un coup, c'est déjà moins intéressant. Chacun de tes programmes doit attendre que le précédent ait finit tout son travail et écrit son résultat avant de pouvoir commencer à son tour à tout charger en mémoire et faire son propre boulot.
Dans ce cas les pipes ne servent qu'a éviter les fichiers temporaires.
Il reste l'avantage d'avoir des plus petits programmes réutilisable, mais un plus gros programme avec des options pour choisir la tâche à éffectuer sera plus intéressant car il permet de factoriser le code. De plus si tu peut lui d'appliquer plusieurs opération en séquence, il n'a pas besoin de recharger les données à chaque fois.
C'est le principe justement de G'MIC : Il n'y a pas un programme séparé pour chaque traitement et une utilisation avec des pipes. Il y a un gros programme et on lui donne la séquence d'opérations à appliquer.
Imagine le temps que mettrait certains des scripts fournis si il fallait transférer l'image entre chacun des traitements... Pour une photo en haute résolution avec les cannaux codés sur 16bits, ça fait un sacré ralentissement.
Pour l'intégration dans Gimp, il y a en gros deux possibilitées :
- Soit on intègre G'MIC c'est-à-dire que l'on automatise la séquence : sauvegarder, lancer G'MIC manuellement, charger ;
- Soit on intègre les fonctions de G'MIC et donc chaque fonction de G'MIC devient une fonction de Gimp.
Il me semble assez évident que, d'un point de vue utilisateur, la deuxième solution est plus puissante. Elle permet de mélanger les différentes fonctions sans se poser de questions. Mais elle est bien plus complèxes à implémenter et maintenir.
La première, par contre, à l'avantage d'être relativement simple à coder et maintenir. Bien sûr, on peut effectuer plein de petits appels et obtenir la même souplesse que dans le deuxième cas, mais c'est au prix d'un aller-retour de l'image à chaque appel.
Dans le cas ou l'on demande à G'MIC d'effectuer toute une série d'opérations, le temps de transfert est négligeable. Mais si l'on souhaite faire d'autre traitements avec Gimp, entre chaque fonction de G'MIC, ce temps de transfert est surement bien plus important.
[^] # 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.
Typiquement, lorsque un problème peut être diviser en plusieurs petites tâches à appliquer en séquence sur les données et que ces données sont traîtées en flux, c'est génial.
En plus, vu la quantité de tels outils déjà disponible, le plus souvent ça économise un max de temps, et sur une machine multi-processeur ça te donne un parallélisme gratuit. Les pipes ont beaucoup d'avantage pour traîter ce genre de données.
Mais dans le cas ou tu travaille sur toutes les données d'un coup, donc en gros : tout charger en mémoire, faire le calcul et sortir tout le résultat d'un coup, c'est déjà moins intéressant. Chacun de tes programmes doit attendre que le précédent ait finit tout son travail et écrit son résultat avant de pouvoir commencer à son tour à tout charger en mémoire et faire son propre boulot.
Dans ce cas les pipes ne servent qu'a éviter les fichiers temporaires.
Il reste l'avantage d'avoir des plus petits programmes réutilisable, mais un plus gros programme avec des options pour choisir la tâche à éffectuer sera plus intéressant car il permet de factoriser le code. De plus si tu peut lui d'appliquer plusieurs opération en séquence, il n'a pas besoin de recharger les données à chaque fois.
C'est le principe justement de G'MIC : Il n'y a pas un programme séparé pour chaque traitement et une utilisation avec des pipes. Il y a un gros programme et on lui donne la séquence d'opérations à appliquer.
Imagine le temps que mettrait certains des scripts fournis si il fallait transférer l'image entre chacun des traitements... Pour une photo en haute résolution avec les cannaux codés sur 16bits, ça fait un sacré ralentissement.
Pour l'intégration dans Gimp, il y a en gros deux possibilitées :
- Soit on intègre G'MIC c'est-à-dire que l'on automatise la séquence : sauvegarder, lancer G'MIC manuellement, charger ;
- Soit on intègre les fonctions de G'MIC et donc chaque fonction de G'MIC devient une fonction de Gimp.
Il me semble assez évident que, d'un point de vue utilisateur, la deuxième solution est plus puissante. Elle permet de mélanger les différentes fonctions sans se poser de questions. Mais elle est bien plus complèxes à implémenter et maintenir.
La première, par contre, à l'avantage d'être relativement simple à coder et maintenir. Bien sûr, on peut effectuer plein de petits appels et obtenir la même souplesse que dans le deuxième cas, mais c'est au prix d'un aller-retour de l'image à chaque appel.
Dans le cas ou l'on demande à G'MIC d'effectuer toute une série d'opérations, le temps de transfert est négligeable. Mais si l'on souhaite faire d'autre traitements avec Gimp, entre chaque fonction de G'MIC, ce temps de transfert est surement bien plus important.