Pyradiomics: Profilage PyRadiomics pour de très grandes segmentations

@blezek J'ai mentionné à @Radiomics/developers que vous rencontreriez des problèmes de performances en essayant d'exécuter des radiomics sur des cerveaux entiers, alors @JoostJM a fait un peu de profilage.

D'après un rapide coup d'œil au code glszm , il semble qu'il y ait beaucoup de place pour optimiser l'implémentation.

Dans le code c ? Avez-vous une idée générale de la façon de l'aborder?

Dans le code c ? Avez-vous une idée générale de la façon de l'aborder?

Peut-être que vous pourriez envisager d'utiliser des threads

Cela dit, l'utilisation de bibliothèques de threads avec le c-code vanille peut être difficile à maîtriser.

Je pense que la mise en œuvre de filtres ITK pourrait être utile (par exemple, en tant que module distant ITK), vous seriez alors en mesure de tirer parti de l'API de traitement d'images et de threading multiplateforme associée. Ces filtres pourraient ensuite être exposés via SimpleITK

@thewtex @jbvimort Je me demande si vous avez des idées ...

Il serait préférable de faire un profilage ligne par ligne, mais je suppose que cet ensemble de boucles imbriquées est assez lent. L'utilisation de numpy.where peut être lente et renverra de longues listes de coordonnées.

Je suis d'accord avec Jc que cette opération pourrait être enfilée puisque chaque pixel doit être indépendant. De plus, une implémentation SimpleITK de la même opération pourrait être beaucoup plus rapide. Mais je commencerais par faire le profilage et voir s'il existe des moyens d'optimiser simplement le code python existant.

@pieper, il ressort du profilage que Joost a déjà fait que _calculateCMatrix représente 77% du temps (si j'interprète correctement le résumé du profilage):

Je vois, vous dites que c'est probablement cet appel à ce code . Oui, cela semble assez intensif en calcul.

Si cette fonctionnalité est vraiment informative et que les masques d'image volumineux sont un cas d'utilisation important, il se peut que l'approche de la « bibliothèque C simple » ne soit pas suffisante, du moins telle qu'elle est actuellement écrite. Il est possible que le code C soit rendu plus efficace ou que nous puissions explorer d'autres options comme le threading ou l'implémentation SimpleITK.

@pieper @fedorov , c'est bien cet appel . Je vais jeter un oeil pour voir si cela peut être rendu plus efficace.

Si je peux, j'aimerais éviter d'implémenter le multithreading ici pour 2 raisons

1. Cela rendra le code C beaucoup plus complexe
2. Lorsque j'extrait des fonctionnalités pour plusieurs patients, j'augmente les performances en multithreading au niveau du patient (chaque patient 1 thread). Dans ce cas, j'ai également défini SimpleITK sur un seul fil pour conserver le seul fil d'extraction du patient.

Par ailleurs, la principale raison pour laquelle c GLSZM prend autant de temps est qu'il nécessite beaucoup de calculs et qu'il est appelé 12 fois (en raison des différentes images dérivées). L'appel au filtre d'image labelshapestistics de SimpleITK est l'appel qui prend le plus de temps pour un seul appel, mais n'est appelé qu'une seule fois par extraction (car il fait partie de la forme et donc uniquement calculé sur le type d'image d'origine).

Quant à l'appel SimpleITK prenant tellement de temps. Cela est dû au calcul du diamètre de Feret (diamètre 3D max).
Si vous exécutez le filtre d'image labelshapestistics avec et sans ce diamètre, il y a une différence de temps de 271053 ms contre 21 ms pour le masque full brain1.

Il existe maintenant un package Python disponible, itk-texturefeatures , qui pourrait être utile ici.

@JoostJM avez-vous jeté un œil à itk-texturefeatures ? Il serait intéressant de savoir comment la vitesse se compare et si les ensembles de fonctionnalités sont comparables à ce que nous avons maintenant dans le code c de pyrradiomics.

https://github.com/InsightSoftwareConsortium/ITKTextureFeatures/tree/2b4544fe39e0ece9007a0d87c396c8586c6f4df5/example

@pieper , Je viens de rentrer de mes vacances, mais c'est certainement intéressant.
J'ai fait du profilage à l'aide de PyRadiomics et d'un masque similaire à celui utilisé par les fonctionnalités de texture ITK (implémentant un calcul par voxel). Les performances de Pyradiomics étaient similaires à celles d'ITK.
L'inconvénient de PyRadiomics est qu'il n'accepte que les entrées 3D, alors qu'ITK est à N dimensions. D'autre part, PyRadiomics atteint cette performance en mode mono-thread et calcule plus de fonctionnalités dans GLCM.

En termes de fonctionnalités, pour autant que je sache, les définitions de formules sont similaires, PyRadiomics ayant plus de fonctionnalités à la fois dans GLCM et GLRLM. Les fonctionnalités de texture d'ITK n'ont qu'une seule fonctionnalité (dans GLCM) que PyRadiomics n'a pas, mais il s'agit d'une implémentation similaire de correlation de PyRadiomics, qui est présente dans ITK sous la forme Haralick's correlation . Cela étant dit, je pense toujours qu'il y aura quelques différences, du fait qu'ITK a utilisé un nombre de bacs fixe, par opposition à la largeur de bac fixe dans PyRadiomics.

Merci d'avoir vérifié @JoostJM -- il semble que nous devrions décider si nous voulons conserver une implémentation indépendante dans PyRadiomics ou travailler avec la communauté ITK pour améliorer itk-texturefeatures. Ma réaction instinctive est de préférer l'effort de la communauté dans la mesure du possible dans l'espoir que la maintenance du code sera plus efficace.