Je n'ai pas essayer G'MIC mais le traitement d'un photo numérique d'un 5M de pixel avec GREYStoration prend plusieurs minutes sur mon P4 2,5GHz...
Il faut donc voir les points suivants :
- combien de temps est perdus dans le chargement déchargement dans G'MIC
- combien de temps je passe à interfacé mon code C++ (G'MIC) avec le code C (Gimp), sachant que le C++ et le C ne font pas toujours bon ménage si on commence à trop vouloir mélanger...
- combien de temps je vais gagner à passer par des appels système ?
- combien de temps mon algorithme de calcul pourra être réduit dans le futur.
Dans les cas de calculs longs avec des temps de transfert court et s'il n'y a pas a court terme de moyen de diminuer le temps de calcul, le passage par pipe est une bonne solution alliant souplesse, modularité, indépendance, maintenance.
Dans mon cas à moi, le code était en fortran 90, le post-traitement en C++ et l'hyperviseur en Perl. Faire parler tout cela via des pipes m'a permis d'avoir une grande souplesse de développement, de perdre des poullièmes de secondes et d'avoir des modules complémentement indépendant tant que le langage dans le pipe suivait une certaine convention.
Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.
[^] # Re: Merci
Posté par Sytoka Modon (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 4.
Il faut donc voir les points suivants :
- combien de temps est perdus dans le chargement déchargement dans G'MIC
- combien de temps je passe à interfacé mon code C++ (G'MIC) avec le code C (Gimp), sachant que le C++ et le C ne font pas toujours bon ménage si on commence à trop vouloir mélanger...
- combien de temps je vais gagner à passer par des appels système ?
- combien de temps mon algorithme de calcul pourra être réduit dans le futur.
Dans les cas de calculs longs avec des temps de transfert court et s'il n'y a pas a court terme de moyen de diminuer le temps de calcul, le passage par pipe est une bonne solution alliant souplesse, modularité, indépendance, maintenance.
Dans mon cas à moi, le code était en fortran 90, le post-traitement en C++ et l'hyperviseur en Perl. Faire parler tout cela via des pipes m'a permis d'avoir une grande souplesse de développement, de perdre des poullièmes de secondes et d'avoir des modules complémentement indépendant tant que le langage dans le pipe suivait une certaine convention.
Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.