Shapeworks: a renderização de volumes de algumas resoluções trava ao usar itkwidgets.view após usar shapeworks em um notebook

Sim, estou tentando executá-lo agora e encontrando a mesma falha, bem aqui:
`` `shapeSeg = shapeSegList [10]
itkw.view (image = sw2vtkImage (shapeSeg),
Slicing_planes = True,
axes = True,
rotate = True,
interpolação = True)

Simplificou o problema e parece que Image :: resample é o culpado aqui. Após a reamostragem, ellipsoid_05 carrega o visualizador enquanto ellipsoid_00 faz com que o kernel trave ao tentar usar itk.view ()

notebooks.zip

Depois de testar isso, algo _pode_ estar errado com Image :: resample wrt itkwidgets.view .
Imagens experimentadas: elipsoid_1mode / segmentations / ellipsoid_00.nrrd e ellipsoid_1mode / segmentations / ellipsoid_05.nrrd
-> 00 falha ao ser plotado quando empacotado por pyvista em uma imagem vtk após a reamostragem
-> 05 funciona bem
=> _both_ funciona bem quando plotado por pyvista
Eu joguei alguns spew de depuração em Image :: resample e não vi nada fora do comum até agora).

Aqui está um caderno simples, se você quiser experimentar.
wishy_washy_resample.ipynb.zip

... e o que parece vazio quando você carrega:

... e como fica quando você o executa. Altere 05 para 00 e execute-o novamente para travar quando o itkw tentar renderizar.

Transpor ou ... A matriz que pode ser renderizada
Se você se lembra, itkwidgets pode renderizar um array numpy diretamente. Mas ele interpreta esse array como a transposição do que é passado, algo que _não_ faz quando um array vtk é usado. Portanto, normalmente transpomos o que obtemos da imagem antes de envolvê-la em um array vtk e simplesmente usamos o array vtk com itkwidgets para manter as coisas simples.

Tentei os dois esta manhã e infelizmente não fez diferença. Transposto ou não, matrizes numpy ou vtk, tudo trava ao tentar renderizar usando itkwidgets após Image.resample.

Copiar ou ... Estou me repetindo?
A matriz proveniente da imagem pode ser o problema. Talvez esteja apontando para uma memória inválida. Então, vamos criar uma cópia!
Depois de copiar o array - em order='C' e order='F' , transpor, modificar, ficar de cabeça para baixo ao compor as funções e pensar de forma desejosa sobre tudo isso, _ ele ainda trava toda vez_.

Isso sugere que o tamanho do array em si pode ser um problema. Uma forma de confirmar isso era chamar a resample com o mesmo espaçamento ( [1,1,2] ), _que funcionou bem_. Outra maneira era criar uma matriz numpy falsa de tamanho questionável. E...
Por favor, rufem os tambores...
apresentando ...
pela primeira vez ... (no GitHub)
Uma reprodução _shapeworks-free_!

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

Então, coloque isso no seu caderno e fume *.

* fumaça implicando acidente, não defendendo a inalação real de nada, observe que esta é uma instalação para não fumantes, não é válida com nenhuma outra oferta, ... de qualquer forma, espero que alguém esteja sorrindo, porque este não é o nosso problema! Exceto que é. 😞

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)

Todos esses exemplos renderizam o visualizador itk quando o shapeworks não é importado.
Ele trava quando o shapeworks é importado.

Hmm, temos alguma interação de biblioteca conda itk / vtk vs shapeworks itk / vtk acontecendo?

Eu acho que o itkwidgets está usando outra versão do itk

A ordem de importação não é importante, mas a ordem de uso é. Isso significa que se você importar tudo, mas usar itkwidgets antes do shapeworks, ele travará quando você usar o shapeworks e vice-versa.

Como a solução para o # 1179 foi simplesmente "não use itk", proponho que resolvamos esse problema da mesma forma. A menos que haja uma opção melhor no momento, vamos remover itkwidgets de nossos notebooks.

Parece um bom plano por enquanto. É razoável remover itkwidgets dos notebooks? Para que estamos usando isso?

Estamos usando para ver as segmentações. Acho que podemos usar pyvista em vez disso

Observe que o pyvista (até onde eu sei) não respeita a meta-informação da imagem (origem, espaçamento do voxel, direção dos eixos), mas o itkwidget sim.

Observe que o pyvista (até onde eu sei) não respeita a meta-informação da imagem (origem, espaçamento do voxel, direção dos eixos), mas o itkwidget sim.

Vamos nos aprofundar nisso, mas deve haver algum respeito pela origem, uma vez que vários volumes podem ser plotados simultaneamente com locais diferentes, e esta imagem mostra que o espaçamento é usado para plotagem. Nossas funções sw2vtkImage simplesmente não o mantiveram (sei que mudei isso em algumas, mas talvez essas estejam no novo branch pybind).

Quero sugerir que lançemos e enviemos isso para a próxima versão, uma vez que tem muitos outros aprimoramentos de Python e notebook e, essencialmente, seremos forçados a reescrevê-los. Talvez apenas deixemos que sejam quebrados. É um problema conhecido em um repositório público e temos uma solução alternativa para o caso de algum usuário encontrá-lo.

(Ainda teremos de modificar o bloco de notas de introdução às segmentações para que seja concluído sem travar, o que significa simplesmente escolher uma imagem arbitrária diferente para demonstrar a renderização.)

Eu concordo. Vamos empurrar para a versão 6.1 e atualizarei as notas de versão e o resumo gráfico para tirar a ênfase das coisas do Python.

Depois de usar uma imagem arbitrária que não trava o visualizador, ela ainda trava em mais 3 lugares que usam a imagem de forma média.
@cchriste

Proponho que excluamos este bloco de notas do lançamento, exceto na documentação.

Funciona para mim. @sheryjoe ?

pyvista mostrando coordenadas lógicas
https://sci.utah.edu/~shapeworks/doc-resources/mp4s/nb-groom-resample.mp4

versus itkwidgets mostrando coordenadas físicas
https://sci.utah.edu/~shapeworks/doc-resources/mp4s/nb-groom-resample-iso.mp4

pyvista mostrando coordenadas lógicas
versus itkwidgets mostrando coordenadas físicas

Dado o problema nº 900, é difícil imaginar que o itk já tenha mostrado as coordenadas físicas.

Para esta imagem (com espaçamento z = 2):

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

O visualizador itk só pode mostrar a versão fora de escala, caso contrário, ele trava.

Aqui está um único volume pyvista mostrando o elipsóide fora de escala e a versão em escala.

Eu realmente não gosto da maneira como o visualizador pyvista mostra os limites em comparação com o visualizador itk.
Mas eles estão corretos e estão mostrando as coordenadas físicas.