Shapeworks: le rendu des volumes de certaines résolutions se bloque lors de l'utilisation de itkwidgets.view après l'utilisation de shapeworks dans un notebook

Créé le 23 mars 2021  ·  22Commentaires  ·  Source: SCIInstitute/ShapeWorks

Auparavant, il s'agissait de «plantages de bloc-notes pour commencer avec les segmentations de toilettage sous MacOS», mais de nombreuses recherches ont permis de découvrir le problème réel, probablement en raison de bibliothèques partagées incompatibles.

Système propre, conda propre.

C'est la cellule qui plante:

shapeSeg = shapeSegList[10]
itkw.view( image          = sw2vtkImage(shapeSeg),
           slicing_planes = True,
           axes           = True,
           rotate         = True,
           interpolation  = True)
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x000000014b76fff3
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0x14b76fff3:
    MALLOC_LARGE           000000014b50a000-000000014b769000 [ 2428K] rw-/rwx SM=PRV  
--> 
    MALLOC_LARGE           000000014b770000-000000014d863000 [ 32.9M] rw-/rwx SM=PRV  

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib        0x00007fff564c85e6 _platform_memmove$VARIANT$Nehalem + 486
1   libvnl.dylib                    0x000000010ae40e6b vnl_vector<double>::operator=(vnl_vector<double> const&) + 139
2   _ITKCommonPython.so             0x000000014ec0d18b vnl_vector<double>::operator=(vnl_vector<double>&&) + 65
3   _ITKCommonPython.so             0x000000014eadec9d 0x14de03000 + 13483165
4   _ITKCommonPython.so             0x000000014e869165 0x14de03000 + 10903909
5   _ITKCommonPython.so             0x000000014ec611a7 itk::ProcessObject::UpdateOutputInformation() + 339
6   _ITKCommonPython.so             0x000000014e47d8fe 0x14de03000 + 6793470
7   _ITKImageGridPython.so          0x00000001538b5619 itk::ProcessObject::UpdateOutputInformation() + 117
8   _ITKImageGridPython.so          0x00000001538b5ebc itk::ProcessObject::UpdateLargestPossibleRegion() + 18
9   _ITKCommonPython.so             0x000000014e10726b 0x14de03000 + 3162731
10  python                          0x00000001044c8843 _PyMethodDef_RawFastCallKeywords + 131
11  python                          0x00000001044c81d6 _PyObject_FastCallKeywords + 598
12  python                          0x0000000104600bb7 call_function + 455
...
bug

Tous les 22 commentaires

Ouais, j'essaie de l'exécuter maintenant et de frapper le même crash, ici:
`` `shapeSeg = shapeSegList [10]
itkw.view (image = sw2vtkImage (shapeSeg),
slicing_planes = Vrai,
axes = Vrai,
rotation = Vrai,
interpolation = Vrai)

Simplifié le problème et il semble que Image :: resample est le coupable ici. Après le rééchantillonnage, ellipsoid_05 charge le visualiseur tandis que ellipsoid_00 provoque le blocage du noyau lors de la tentative d'utilisation de itk.view ()

Screen Shot 2021-03-24 at 11 02 20 PM

Screen Shot 2021-03-24 at 11 01 06 PM

Après avoir testé ceci, quelque chose _peut_ être mal avec Image :: resample wrt
Images essayées: ellipsoid_1mode / segmentations / ellipsoid_00.nrrd et ellipsoid_1mode / segmentations / ellipsoid_05.nrrd
-> 00 ne peut pas être tracé lorsqu'il est enveloppé par pyvista dans une image vtk après le rééchantillonnage
-> 05 fonctionne bien
=> _les deux_ fonctionnent bien lorsqu'ils sont tracés par pyvista
J'ai lancé du débogage dans Image :: resample et je n'ai rien vu d'extraordinaire jusqu'à présent).

Voici un cahier simple si vous souhaitez expérimenter.
wishy_washy_resample.ipynb.zip

... et à quoi il ressemble vide lorsque vous le chargez:
Screen Shot 2021-03-24 at 7 59 23 PM

... et à quoi il ressemble lorsque vous l'exécutez. Changez le 05 en 00 et exécutez-le à nouveau pour qu'il plante quand itkw essaie de rendre.
Screen Shot 2021-03-24 at 7 55 29 PM

Transposer ou ... le tableau qui pourrait être rendu
Si vous vous en souvenez, itkwidgets peut rendre un tableau numpy directement. Mais il interprète ce tableau comme la transposition de ce qui est passé, ce qu'il ne fait pas quand un tableau vtk est utilisé. Par conséquent, nous transposons généralement ce que nous obtenons de l'image avant de l'envelopper dans un tableau vtk, et utilisons simplement le tableau vtk avec itkwidgets pour garder les choses simples.

J'ai essayé les deux ce matin et malheureusement cela ne fait aucune différence. Transposés ou non, tableaux numpy ou vtk, tout se bloque lors de la tentative de rendu en utilisant itkwidgets après Image.resample.

Copier ou ... est- ce que je me répète?
Le tableau provenant de l'image peut être le problème. Peut-être que cela pointe vers une mémoire invalide. Alors créons une copie!
Après avoir copié le tableau - à la fois dans order='C' et order='F' , transposant, modifiant, debout sur ma tête tout en composant les fonctions, et en pensant à tout cela, _il plante toujours à chaque fois_.

Cela suggère que la taille du tableau lui-même pourrait être un problème. Une façon de confirmer cela était d'appeler le rééchantillonnage avec le même espacement ( [1,1,2] ), ce qui a bien fonctionné. Une autre façon était de créer un faux tableau numpy de ladite taille douteuse. Et...
Roulement de tambour s'il vous plaît...
en présentant...
pour la toute première fois ... (dans GitHub)
Une repro sans forme!

array = np.ndarray([109, 77, 204])
itkw.view(image = array)

Alors allez mettre ça dans votre cahier et fumez-le.

* fumée impliquant un accident, ne préconisant aucune inhalation réelle de quoi que ce soit, notez qu'il s'agit d'un établissement non-fumeur, non valable avec aucune autre offre, ... de toute façon, j'espère que quelqu'un sourit, car ce n'est pas notre problème! Sauf que ça l'est. 😞

array = np.ndarray([109, 77, 204])
itkw.view(image = array)
array = np.ndarray([109, 109, 204])
itkw.view(image = array)



md5-047f51858ff0a12b3bec85f300fc2efa



array = np.ndarray([109, 109, 109])
itkw.view(image = array)

Tous ces exemples rendent la visionneuse itk lorsque shapeworks n'est pas importé.
Il se bloque lors de l'importation de shapeworks.

Hmm, avons-nous une interaction entre les bibliothèques conda itk / vtk et shapeworks itk / vtk?

Je suppose que itkwidgets utilise une autre version d'itk

L'ordre d'importation n'est pas important, mais l'ordre d'utilisation l'est. Cela signifie que si vous importez tout, mais que vous utilisez itkwidgets avant les shapeworks, il se bloque lorsque vous utilisez des shapeworks, et vice versa.

Puisque la solution à # 1179 était simplement "ne pas utiliser itk", je propose que nous résolvions ce problème de la même manière. À moins qu'il n'y ait une meilleure option pour le moment, supprimons itkwidgets de nos blocs-notes.

Cela semble être un bon plan pour le moment. Est-il raisonnable de supprimer itkwidgets des ordinateurs portables? Pourquoi l'utilisons-nous?

Nous l'utilisons pour visualiser les segmentations. Je pense que nous pouvons utiliser pyvista à la place

Notez que pyvista (pour autant que je sache) ne respecte pas les méta-informations de l'image (origine, espacement des voxels, direction des axes), mais itkwidget le fait.

Notez que pyvista (pour autant que je sache) ne respecte pas les méta-informations de l'image (origine, espacement des voxels, direction des axes), mais itkwidget le fait.

Nous allons approfondir cela, mais il doit y avoir un certain respect pour l'origine car plusieurs volumes peuvent être tracés simultanément avec différents emplacements, et cette image montre que l'espacement est utilisé pour le traçage. Nos fonctions sw2vtkImage ne l'ont tout simplement pas conservée (je sais que j'ai changé cela dans certaines, mais peut-être qu'elles sont dans la nouvelle branche pybind).

Screen Shot 2021-03-26 at 1 34 32 PM

Je veux suggérer de publier et de pousser cela dans la prochaine version car celle-ci a de nombreuses autres améliorations de python et de notebook, et nous serons essentiellement obligés de les réécrire. Peut-être que nous les laissons simplement être brisés. C'est un problème connu dans un référentiel public et nous avons une solution de contournement au cas où des utilisateurs le rencontreraient.

(Nous devrons toujours modifier le bloc-notes de démarrage avec les segmentations pour qu'il se termine sans planter, ce qui signifie simplement choisir une image arbitraire différente pour démontrer le rendu.)

Je suis d'accord. Poussons cela à la version 6.1 et je mettrai à jour les notes de publication et le résumé graphique pour désaccentuer les choses python.

Après avoir utilisé une image arbitraire qui ne plante pas la visionneuse, elle plante toujours à 3 autres endroits qui utilisent l'image de forme moyenne.
@cchriste

Je propose d'exclure ce cahier de la version sauf dans la documentation.

Travaille pour moi. @sheryjoe ?

pyvista montrant les coordonnées logiques
versus itkwidgets montrant les coordonnées physiques

Compte tenu du problème n ° 900, il est difficile d'imaginer qu'il ait déjà montré des coordonnées physiques.

Pour cette image (avec espacement z = 2):

{
    dims: [93, 87, 94],
    origin: [-24, -19, -21],
    size: [93, 87, 188],
    spacing: [1, 1, 2]
}

La visionneuse itk ne peut afficher que la version non mise à l'échelle, sinon elle se bloque.
Screen Shot 2021-03-30 at 3 57 34 PM

Voici un seul volume pyvista montrant à la fois l'ellipsoïde non mis à l'échelle et la version à l'échelle.
Screen Shot 2021-03-30 at 3 56 20 PM

Je n'aime pas vraiment la façon dont la visionneuse pyvista montre les limites par rapport à la visionneuse itk.
Mais ils sont corrects et ils affichent des coordonnées physiques.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

akenmorris picture akenmorris  ·  32Commentaires

iyerkrithika21 picture iyerkrithika21  ·  12Commentaires

jadie1 picture jadie1  ·  8Commentaires

iyerkrithika21 picture iyerkrithika21  ·  7Commentaires

akenmorris picture akenmorris  ·  23Commentaires