Pyradiomics: Valeurs des caractéristiques d'ondelettes incohérentes entre v1.2.0 et v1.3.0
Salut! J'ai pris en charge un projet qui a été précédemment lancé par quelqu'un qui utilisait pyradiomics v1.2. Étant donné que je viens de commencer, j'ai opté pour la dernière version (v.1.3). Pour m'assurer que j'étais sur la bonne voie, je comparais les caractéristiques résultant de mes courses avec la personne qui travaillait avec la v1.2 et j'ai trouvé des écarts importants dans les caractéristiques calculées à partir des images filtrées par ondelettes. J'ai pu identifier deux problèmes:
Problème 1:
Dans la version 1.3, j'ai constaté que certains des noms de décomposition n'étaient pas attribués à la bonne image de décomposition. J'ai découvert cela quand j'ai vu qu'il y avait une symétrie presque parfaite par rapport à la version 1.2.
Ceci est spécifique aux décompositions en ondelettes dont les noms ne sont pas des palindromes (par exemple, les caractéristiques «LLL» étaient les mêmes dans toutes les versions alors que HHL (v1.3) = LHH (v.1.2), LLH (v1.3) = HHL (v.1.2 ), etc). En creusant un peu dans la fonction getWaveletImage dans imageoperations.py, j'ai vu qu'il y avait l'ajout des lignes suivantes dans la v1.3:
axes = {2, 1, 0} # ensemble
si kwargs.get ('force2D', False):
axes - = {kwargs.get ('force2Ddimension', 0)} # set
approx, ret = _swt3 (inputImage, kwargs.get ('wavelet', 'coif1'), kwargs.get ('level', 1), kwargs.get ('start_level', 0), axes = tuple (axes))
D'après ma compréhension de pywavelet, les axes sont la variable dont l'ordre détermine l'ordre des lettres dans le nom de la décomposition. Je me demandais pourquoi c'est un ensemble? Il me semble que son ordre serait alors imprévisible lors de la conversion en tuple dans la fonction _swt3 qui pourrait alors changer le nom de la décomposition et les étiquettes de caractéristiques. Lorsque je change la variable des axes en liste, je ne reçois plus le problème.
Problème 2:
Lorsque j'ai résolu le problème ci-dessus, j'ai commencé à obtenir les mêmes valeurs de fonctionnalités d'ondelettes que la v1.2 pour certaines images mais pas d'autres. Et cette fois, les écarts étaient aléatoires (et significatifs).
En regardant à nouveau la fonction getWaveletImage dans imageoperations.py v1.3, il semble que les images soient remplies si leurs dimensions ne sont pas divisibles par 2. Cela semble être une contrainte placée par des pywavelets où la longueur du signal doit être divisible par 2 ** niveau (2 dans ce cas). Je ne pense pas que le même remplissage se produise dans la version 1.2. En effet, quand je regarde les dimensions des images que j'ai testées, les images qui correspondent parfaitement à la v1.2 avaient des dimensions paires (pas de rembourrage en v.1.3) alors que celles qui n'avaient pas au moins une dimension impaire (rembourrage en v1 .3). Est-il prudent de dire que la v1.3 a les valeurs de caractéristiques les plus précises pour les images filtrées par ondelettes (à l'exception du premier problème)?
sandfis
Tous les 11 commentaires
@sandfis merci d'avoir enquêté là-
Deux autres commits liés qui se sont produits entre 1.2 et 1.3:
- https://github.com/Radiomics/pyradiomics/commit/7ff05482d3615e26ff7439e8f9044aefcba50a9a (BUG: Correction du redimensionnement pour le filtrage par ondelettes. Le redimensionnement ne brouille plus l'image.)
- https://github.com/Radiomics/pyradiomics/commit/67845cfe7434e42fc4dccd4fb15f99961001c874 (ENH: changement du mode pad de constant à wrap)
cc: @michaelschwier
fedorov
le 21 juin 2018
@sandfis à propos de vos notes:
- problème 1: votre solution a du sens pour moi. Attendons d'entendre @JoostJM , mais je pense que ce serait génial si vous pouviez soumettre un PR avec le correctif.
- problème 2: Je pense que ce commit auquel j'ai fait référence plus tôt est probablement à blâmer: https://github.com/Radiomics/pyradiomics/commit/67845cfe7434e42fc4dccd4fb15f99961001c874. Je ne dirais pas que l'un est plus précis que l'autre, c'est simplement que les conventions ont changé et que nous n'avons pas communiqué ni même documenté ce changement. Je pense que nous devrions modifier les informations de version pour informer les utilisateurs que les fonctionnalités d'ondelettes ne seront pas les mêmes que dans 1.2 pour les images dont la taille n'est pas divisible par 2.
fedorov
le 21 juin 2018
En fait, le problème 2 est très certainement lié à 7ff05482d3615e26ff7439e8f9044aefcba50a9a. Le rembourrage pour les images aux dimensions impaires n'était pas correct auparavant!
michaelschwier
le 21 juin 2018
Super, merci @fedorov! J'attendrai que @JoostJM pèse aussi
sandfis
le 21 juin 2018
Je dois dire que si c'est effectivement la source de l'écart, il est remarquable de constater à quel point ce changement de stratégie de remplissage a introduit une différence.
@sandfis pensez -vous que vous pourriez poursuivre vos investigations, et voir si le fait de revenir sur le commit référencé ci-dessus ferait correspondre les valeurs? Ce serait super utile.
fedorov
le 21 juin 2018
@fedorov @sandfis Désolé, j'aurais peut-être dû l'expliquer un peu plus en détail auparavant, car ce n'est pas évident à partir du seul changement de code sans savoir ce que fait le redimensionnement de numpy: La façon dont le remplissage était fait avant (avec redimensionnement), a littéralement brouillé le image! Le redimensionnement ajouterait des zéros à la fin du tampon de tableau / matrice (pas à la fin de chaque dimension). Voir l'exemple 3 «Agrandissement d'un tableau» ici: https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.ndarray.resize.html#numpy.ndarray.resize
D'où la grande différence, le calcul des ondelettes pour les images de dimensions impaires était malheureusement complètement faux avant 7ff05482d3615e26ff7439e8f9044aefcba50a9a
michaelschwier
le 21 juin 2018
@michaelschwier merci d'avoir clarifié cela, en effet je l'ai complètement manqué dans https://github.com/Radiomics/pyradiomics/commit/7ff05482d3615e26ff7439e8f9044aefcba50a9a. Je n'ai regardé que le deuxième commit pertinent et j'ai pensé que le changement consistait à passer de pad à wrap . En effet, maintenant que vous l'expliquez, c'était complètement faux. Je pense donc que cela devrait être répertorié dans la section "Corrections de bogues" de https://github.com/Radiomics/pyradiomics/releases/tag/1.3.0.
Maintenant, que faisons-nous de tous ces articles qui ont réussi à développer de nouvelles signatures radiomiques prédisant la maladie et l'éradication du cancer sur la base des fonctionnalités d'ondelettes implémentées dans la v1.2.0? 🤣
fedorov
le 21 juin 2018
Merci @michaelschwier
En effet nous pouvons voir que les fonctionnalités s'alignent avec la v1.2 lors du retour de 7ff0548
sandfis
le 21 juin 2018
Désolé pour la réponse tardive!
Je suis d'accord avec @fedorov et @michaelschwier , bien que je pense que cela devrait être documenté dans la prochaine version, car ce changement est dans le master actuel, et après la sortie de la v1.3.0.
Ai-je raison de supposer que v1.3 signifie ici le maître actuel?
De plus, en ce qui concerne le problème 1, un ensemble est en effet incorrect ici. Cependant, le passage à un tuple ne fonctionne pas, car vous ne pouvez pas supprimer des éléments comme cela serait nécessaire lors de l'extraction d'entités en 2D (au cours de laquelle l'ondelette sera également calculée en 2D, et nécessite donc la suppression de l'axe entre les plans).
J'ai résolu ce problème en utilisant une liste et list.remove() , je transmettrai bientôt ce correctif au maître.
JoostJM
le 26 juin 2018
voir 4027a52
JoostJM
le 26 juin 2018
Merci @JoostJM! En effet, je travaillais avec le maître actuel.
sandfis
le 26 juin 2018
Questions connexes
jvanlunenburg
·
5Commentaires
2019lili
·
5Commentaires
lisherlock
·
12Commentaires
mattwarkentin
·
13Commentaires
indranilmallick
·
10Commentaires
Commentaire le plus utile
Merci @michaelschwier
En effet nous pouvons voir que les fonctionnalités s'alignent avec la v1.2 lors du retour de 7ff0548