G'mic a l'air intéressant de part son positionnement.
Je travaille également dans un labo de traitement de l'image et c'est assez surprenant de voir le peu d'outils existant entre le "traitement d'image" façon gimp (2D, image "isolée") et la programmation directe en C/C++ (par ex.) avec des biblio genre openCv, imagemagick, fftw ... sur des images 3D.
Sur un projet, j'avais choisi à l'origine de couper la poire en deux en bossant avec Octave qui offre une panoplie plus large et plus souple dans le traitement d'image (pas toujours en 3D, malheuresement), mais j'avais été assez vite refroidi par les temps de calcul quand les traitements concernent des images volumineuses, (genre 512^3, double flottants, complexes 8] !) malgré l'écriture de fonctions en C++ pour Octave ...
La "solution" avait alors été de tout recoder en C/c++, ce qui peut etre un peu lourd pour des essais préliminaires...
ImageJ (en java) peut aussi etre intéressant en 3D dans certains cas.
[^] # Re: vs imagemagick
Posté par Mat . En réponse à la dépêche G'MIC : Un nouvel outil libre de manipulation d'images.. Évalué à 1.
Je travaille également dans un labo de traitement de l'image et c'est assez surprenant de voir le peu d'outils existant entre le "traitement d'image" façon gimp (2D, image "isolée") et la programmation directe en C/C++ (par ex.) avec des biblio genre openCv, imagemagick, fftw ... sur des images 3D.
Sur un projet, j'avais choisi à l'origine de couper la poire en deux en bossant avec Octave qui offre une panoplie plus large et plus souple dans le traitement d'image (pas toujours en 3D, malheuresement), mais j'avais été assez vite refroidi par les temps de calcul quand les traitements concernent des images volumineuses, (genre 512^3, double flottants, complexes 8] !) malgré l'écriture de fonctions en C++ pour Octave ...
La "solution" avait alors été de tout recoder en C/c++, ce qui peut etre un peu lourd pour des essais préliminaires...
ImageJ (en java) peut aussi etre intéressant en 3D dans certains cas.