Shapeworks: Bater com "femur --groom_images" no MacOS

Ele trava com tiny_test?

O tiny_test não falha.

Pode ter algo a ver com os fêmures refletidos, porque o minúsculo teste deixou apenas os fêmures.

Atualização: Verifiquei duas vezes e parece funcionar no Linux.

Eu tentei executar o tiny_test com 2 fêmures esquerdos e um fêmur direito. Não há problemas aí.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000016b8612ad libvnl_algo.dylib`vnl_qr<double>::vnl_qr(this=0x00007ffeefbfd568, M=0x00007ffeefbfd6f0) at vnl_qr.hxx:51:24 [opt]
    frame #1: 0x000000016b85cf1d libvnl_algo.dylib`double vnl_determinant<double>(M=<unavailable>, balance=<unavailable>) at vnl_determinant.hxx:107:14 [opt]
    frame #2: 0x00000003dec807ac _ITKIOImageBasePython.so`___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252
    frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so`___lldb_unnamed_symbol7056$$_ITKIOImageBasePython.so + 132
    frame #4: 0x00000003dec80586 _ITKIOImageBasePython.so`___lldb_unnamed_symbol9956$$_ITKIOImageBasePython.so + 38
    frame #5: 0x00000003dea1d188 _ITKIOImageBasePython.so`___lldb_unnamed_symbol1480$$_ITKIOImageBasePython.so + 1560
    frame #6: 0x00000003ded50753 _ITKIOImageBasePython.so`itk::ProcessObject::UpdateOutputInformation() + 351
    frame #7: 0x00000003dec7fec2 _ITKIOImageBasePython.so`___lldb_unnamed_symbol9945$$_ITKIOImageBasePython.so + 70
    frame #8: 0x00000003ded5b6f4 _ITKIOImageBasePython.so`itk::DataObject::Update() + 18
    frame #9: 0x000000041a65c177 _ITKCommonPython.so`___lldb_unnamed_symbol8759$$_ITKCommonPython.so + 58
    frame #10: 0x000000010002c843 python`_PyMethodDef_RawFastCallKeywords + 131
    frame #11: 0x000000010002c1d6 python`_PyObject_FastCallKeywords + 598
    frame #12: 0x0000000100164bb7 python`call_function + 455
    frame #13: 0x000000010015c604 python`_PyEval_EvalFrameDefault + 20180
    frame #14: 0x0000000100155f04 python`_PyEval_EvalCodeWithName + 532
    frame #15: 0x000000010002c5e3 python`_PyFunction_FastCallKeywords + 403
    frame #16: 0x0000000100164aa7 python`call_function + 183
    frame #17: 0x000000010015c604 python`_PyEval_EvalFrameDefault + 20180
    frame #18: 0x000000010002c535 python`_PyFunction_FastCallKeywords + 229
    frame #19: 0x0000000100164aa7 python`call_function + 183
    frame #20: 0x000000010015cdb0 python`_PyEval_EvalFrameDefault + 22144
    frame #21: 0x0000000100155f04 python`_PyEval_EvalCodeWithName + 532
    frame #22: 0x000000010002c5e3 python`_PyFunction_FastCallKeywords + 403
    frame #23: 0x0000000100164aa7 python`call_function + 183
    frame #24: 0x000000010015c604 python`_PyEval_EvalFrameDefault + 20180
    frame #25: 0x0000000100155f04 python`_PyEval_EvalCodeWithName + 532
    frame #26: 0x00000001001c1afb python`PyRun_FileExFlags + 235
    frame #27: 0x00000001001c14c6 python`PyRun_SimpleFileExFlags + 502
    frame #28: 0x00000001001ede30 python`pymain_run_file + 160
    frame #29: 0x00000001001ed72b python`pymain_run_filename + 123
    frame #30: 0x00000001001ecf11 python`pymain_run_python + 145
    frame #31: 0x00000001001ecb8b python`pymain_main + 27
    frame #32: 0x00000001000018c9 python`main + 89
    frame #33: 0x00007fff6aedfcc9 libdyld.dylib`start + 1
    frame #34: 0x00007fff6aedfcc9 libdyld.dylib`start + 1

Isso pode estar relacionado a # 1168?

Por que ITKIOImageBasePython.so está aparecendo neste rastreamento de pilha? Achei que estávamos usando vínculos python do shapeworks (por exemplo, classe Image).

Além disso, alguns avisos lldb surgiram logo antes de travar:

2021-03-25 11:57:01.360622-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:01.360667-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:01.905525-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:01.905556-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:02.113545-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:02.113577-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:02.646500-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:02.646531-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:03.535838-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:03.535870-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:05.224328-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:05.224362-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.

Isso está acontecendo na etapa de centralização no caso de uso do átrio esquerdo também?

Também trava na depuração? Ele pode divulgar um rastreamento de pilha mais completo. Desde a
A imagem é construída em torno de itk :: Image algumas chamadas para funções de Imagem do ShapeWorks
pode simplesmente ser otimizado.

Há muito tempo e muito longe (o galho pode não existir mais) tentei construir
ligações Python do itk junto com itk em build_dependencies, mas eu não era
bem-sucedido. Acho que vale a pena tentar novamente, especialmente porque conda / pip é
notavelmente instalando diferentes versões de alguns, mas não todos, itk python
componentes (5.0 e 5.1), uma receita flagrante para problemas.

Na quinta-feira, 25 de março de 2021 às 11h59 Alan Morris @ . * >
escreveu:

• thread # 1, queue = 'com.apple.main-thread', motivo de parada = EXC_BAD_ACCESS (código = 1, endereço = 0x0)
  
  
  
  • frame # 0: 0x000000016b8612ad libvnl_algo.dylib vnl_qr<double>::vnl_qr(this=0x00007ffeefbfd568, M=0x00007ffeefbfd6f0) at vnl_qr.hxx:51:24 [opt] frame #1: 0x000000016b85cf1d libvnl_algo.dylib double vnl_determinant(M =, equilíbrio =) em vnl_determinant. hxx: 107 : 14 [opt]
    
    frame # 2: 0x00000003dec807ac _ITKIOImageBasePython.so ___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252 frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so ___ lldb_unnamed_symbol7056 $$ _ ITKIOImageBasePython.so + 132
    
    frame # 4: 0x00000003dec80586 _ITKIOImageBasePython.so ___lldb_unnamed_symbol9956$$_ITKIOImageBasePython.so + 38 frame #5: 0x00000003dea1d188 _ITKIOImageBasePython.so ___ lldb_unnamed_symbol1480 $$ _ ITKIOImageBasePython.so + 1560
    
    frame # 6: 0x00000003ded50753 _ITKIOImageBasePython.so itk::ProcessObject::UpdateOutputInformation() + 351 frame #7: 0x00000003dec7fec2 _ITKIOImageBasePython.so ___ lldb_unnamed_symbol9945 $$ _ ITKIOImageBasePython.so + 70
    
    frame # 8: 0x00000003ded5b6f4 _ITKIOImageBasePython.so itk::DataObject::Update() + 18 frame #9: 0x000000041a65c177 _ITKCommonPython.so ___ lldb_unnamed_symbol8759 $$ _ ITKCommonPython.so + 58
    
    frame # 10: 0x000000010002c843 python _PyMethodDef_RawFastCallKeywords + 131 frame #11: 0x000000010002c1d6 python _PyObject_FastCallKeywords + 598
    
    frame # 12: 0x0000000100164bb7 python call_function + 455 frame #13: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180
    
    frame # 14: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532 frame #15: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403
    
    frame # 16: 0x0000000100164aa7 python call_function + 183 frame #17: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180
    
    frame # 18: 0x000000010002c535 python _PyFunction_FastCallKeywords + 229 frame #19: 0x0000000100164aa7 python call_function + 183
    
    frame # 20: 0x000000010015cdb0 python _PyEval_EvalFrameDefault + 22144 frame #21: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532
    
    frame # 22: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403 frame #23: 0x0000000100164aa7 python call_function + 183
    
    frame # 24: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180 frame #25: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532
    
    frame # 26: 0x00000001001c1afb python PyRun_FileExFlags + 235 frame #27: 0x00000001001c14c6 python PyRun_SimpleFileExFlags + 502
    
    frame # 28: 0x00000001001ede30 python pymain_run_file + 160 frame #29: 0x00000001001ed72b python pymain_run_filename + 123
    
    frame # 30: 0x00000001001ecf11 python pymain_run_python + 145 frame #31: 0x00000001001ecb8b python pymain_main + 27
    
    frame # 32: 0x00000001000018c9 python main + 89 frame #33: 0x00007fff6aedfcc9 libdyld.dylib start + 1
    
    frame # 34: 0x00007fff6aedfcc9 libdyld.dylib`start + 1
  
  

Isso poderia estar relacionado a # 1168
https://github.com/SCIInstitute/ShapeWorks/issues/1168

-
Você está recebendo isto porque foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/1179#issuecomment-807193351 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAJT3EKCRFSERHDJ5XDPHCDTFN2ZPANCNFSM4ZZUXDBQ
.

Atualizar. Ok, fiquei confuso com a saída do Python, presumi que ainda estava na etapa central, pois não havia saída adicional. Ele está travando em FindReferenceImage:

    dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

Meu palpite é que o problema é que temos duas bibliotecas ITK diferentes carregadas na memória. 👎

Há muito tempo e muito longe (o branch pode não existir mais), tentei construir ligações Python do itk junto com itk em build_dependencies, mas não tive sucesso. Suspeito que vale a pena tentar novamente, especialmente porque conda / pip está notavelmente instalando diferentes versões de alguns, mas não todos, componentes itk python (5.0 e 5.1), uma receita óbvia para problemas.

Concordo que isso pode resolver o problema, mas e quanto ao # 1168. Precisamos então construir itkwidgets do zero e fornecê-lo também para que seja construído com nosso ITK?

Concordo que isso pode resolver o problema, mas e quanto ao # 1168. Precisamos então construir itkwidgets do zero e fornecê-lo também para que seja construído com nosso ITK?

Se este for um problema de biblioteca compartilhada, talvez possamos definir LD_LIBRARY_PATH antes de executar o notebook.
atualização: eu tentei isso e o resultado foi o mesmo
update2: Eu tentei apenas o caso de uso # 1168, não este.

Ele está travando em FindReferenceImage:

    dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

O ShapeWorks não está envolvido nesta chamada. Gostaria de saber se mais informações poderiam ser limpas executando isso em pdb :
python -m pub RunUseCase.py --use_case femur --groom_images (então pressione 'r' para executar)

(Estou executando isso agora. Quanto tempo leva para travar? Alguém conseguiu reduzir isso?)
update: leva tanto tempo (~ uma hora), mas menos útil é que só relata uma falha de seg e nem deixa você no depurador. Não vejo uma chamada para scripts externos, então estou confuso com isso.

O problema parece ser que a biblioteca Python ITK está resolvendo e chamando nossa biblioteca VXL, e não aquela com a qual foi construída:

  * frame #0: 0x000000016b8612ad libvnl_algo.dylib`vnl_qr<double>::vnl_qr(this=0x00007ffeefbfd568, M=0x00007ffeefbfd6f0) at vnl_qr.hxx:51:24 [opt]
    frame #1: 0x000000016b85cf1d libvnl_algo.dylib`double vnl_determinant<double>(M=<unavailable>, balance=<unavailable>) at vnl_determinant.hxx:107:14 [opt]
    frame #2: 0x00000003dec807ac _ITKIOImageBasePython.so`___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252
    frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so`___lldb_unnamed_symbol7056$$_ITKIOImageBasePython.so + 132

Lembre-se de que construímos nosso ITK com um VXL / VNL alternativo, não o ITK. libvnl_algo.dylib é nosso, _ITKIOImageBasePython.so é de Conda.

Estamos mixando versões diferentes, então não é surpreendente que ele esteja travando.

@archanasri e eu acabamos de tentar inverter a ordem de
Acho que a solução para o problema # 1168 é simplesmente construirmos itkwidgets (estamos tentando isso agora).
Para este problema, podemos apontar para nosso vnl como apontamos para nosso eigen ?

Já temos ITK usando nosso VXL.

-DITK_USE_SYSTEM_VXL=on -DVXL_DIR=${INSTALL_DIR}

Atualizar. Ok, fiquei confuso com a saída do Python, presumi que ainda estava na etapa central, pois não havia saída adicional. Ele está travando em FindReferenceImage:

    dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

Meu palpite é que o problema é que temos duas bibliotecas ITK diferentes carregadas na memória. 👎

Em vez de usar python itk, podemos usar shapeworks.Image.toArray (). Então eu substituí

dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

com

img = Image(inDataList[i])
tmp = img.toArray()
dim = tmp.shape

Não trava agora.

Bom @archanasri. Sim, achei que poderíamos contornar dessa forma. Basicamente, precisamos ter certeza de não usar python itk + our itk ao mesmo tempo. Eu acho que o problema itkwidgets é o maior problema, já que presumo que ele usa a interface Python ITK internamente.

Sim e não somos capazes de construir itkwidgets.
Precisamos encontrar uma maneira de o itkwidgets usar nosso itk.

Sim e não somos capazes de construir itkwidgets.
Precisamos encontrar uma maneira de o itkwidgets usar nosso itk.

No itkwidgets 0.32.0 (última versão marcada) setup.py, ele especifica estes requisitos:

    'install_requires': [
        'colorcet>=2.0.0',
        'itk-core>=5.1.0.post2',
        'itk-filtering>=5.1.0.post2',
        'itk-meshtopolydata>=0.6.2',
        'ipydatawidgets>=4.0.1',
        'ipywidgets>=7.5.1',
        'ipympl>=0.4.1',
        'matplotlib',
        'numpy',
        'six',
        'zstandard',
    ],

Para itk, acho que isso nos leva de volta à construção do python.
Outra maneira de abordar isso seria garantir que essas são as versões instaladas por pip (principalmente) e conda.
As versões de tudo isso em meu sistema são todas mais recentes.

Aqui está o que eu tenho:

(shapeworks) cam<strong i="15">@ananda</strong>:~/code/ShapeWorks/ShapeWorks/Examples/Python$ conda list | grep itk
itk                       5.0.1                    pypi_0    pypi
itk-core                  5.1.2                    pypi_0    pypi
itk-filtering             5.1.2                    pypi_0    pypi
itk-io                    5.0.1                    pypi_0    pypi
itk-meshtopolydata        0.6.3                    pypi_0    pypi
itk-numerics              5.1.2                    pypi_0    pypi
itk-registration          5.0.1                    pypi_0    pypi
itk-segmentation          5.0.1                    pypi_0    pypi
itkwidgets                0.32.0                   pypi_0    pypi
(shapeworks) cam<strong i="16">@ananda</strong>:~/code/ShapeWorks/ShapeWorks/Examples/Python$ conda list | grep ipy
brotlipy                  0.7.0           py37hf967b71_1001    conda-forge
ipycanvas                 0.8.2                    pypi_0    pypi
ipydatawidgets            4.2.0                    pypi_0    pypi
ipyevents                 0.8.2                    pypi_0    pypi
ipykernel                 5.5.0            py37he01cfaa_1    conda-forge
ipympl                    0.7.0                    pypi_0    pypi
ipython                   7.21.0           py37he01cfaa_0    conda-forge
ipython_genutils          0.2.0                      py_1    conda-forge
ipyvtk-simple             0.1.4                    pypi_0    pypi
ipywidgets                7.6.3                    pypi_0    pypi

Uma bandeira vermelha são as versões 5.0.1 de itk-io, -registration, -segmentation e, acima de tudo, o próprio itk.

Eu atualizei as instalações do pip para o mais recente (havia algum motivo pelo qual não podíamos fazer isso, mas deixando isso de lado por enquanto) e reconstruí todas as dependências. # 1168 ainda trava das mesmas maneiras descritas nele.

Fixo.