Shapeworks: Сбой при использовании "femur --groom_images" на MacOS

Созданный на 25 мар. 2021  ·  23Комментарии  ·  Источник: SCIInstitute/ShapeWorks

$ python RunUseCase.py --use_case femur --groom_images

...

##### Центровка

Входное имя файла: Output / femur / groomed / com_aligned / images / m03_L_1x_hip.isores.pad.com.nrrd
Имя выходного файла: Output / femur / groomed / centered / images / m03_L_1x_hip.isores.pad.com.center.nrrd
Входное имя файла: Output / femur / groomed / com_aligned / images / m04_L_1x_hip.isores.pad.com.nrrd
.....
Входное имя файла: Output / femur / groomed / com_aligned / images / n19_L_1x_hip.isores.pad.com.nrrd
Выходное имя файла: Output / femur / groomed / centered / images / n19_L_1x_hip.isores.pad.com.center.nrrd
Входное имя файла: Output / femur / groomed / com_aligned / images / n19_R_1x_hip.reflect.isores.pad.com.nrrd
Выходное имя файла: Output / femur / groomed / centered / images / n19_R_1x_hip.reflect.isores.pad.com.center.nrrd
zsh: ошибка сегментации python RunUseCase.py --use_case femur --groom_images

Это было на MacOS с RC10.

Все 23 Комментарий

Вылетает из-за tiny_test?

Tiny_test не дает сбоев.

Возможно, это имеет какое-то отношение к отраженным бедрам, потому что крошечный тест оставил только бедренные кости.

Обновление: я дважды проверил, и, похоже, он работает в Linux.

Я пробовал запустить tiny_test с двумя бедрами слева и одной правой. Там нет проблем.

* 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

Может ли это быть связано с # 1168?

Почему ITKIOImageBasePython.so отображается в этой трассировке стека? Я думал, мы использовали привязки python shapeworks (например, класс Image)?

Кроме того, некоторые предупреждения lldb выдает непосредственно перед сбоем:

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.

Происходит ли это также на шаге центрирования в варианте использования левого предсердия?

При отладке тоже вылетает? Это может раскрыть более полную трассировку стека. С
Изображение построено вокруг itk :: Image, некоторые вызовы функций ShapeWorks Image
может быть просто оптимизирован.

Давным-давно и далеко (может быть, ветки уже нет) я пытался построить
привязки itk к Python вместе с itk в build_dependencies, но я не был
успешный. Я подозреваю, что стоит еще раз попробовать, тем более что conda / pip
в частности, установка разных версий некоторых, но не всех, itk python
компоненты (5.0 и 5.1), вопиющий рецепт неприятностей.

В чт, 25 марта 2021 г., в 11:59 Алан Моррис @ . * >
написал:

  • поток # 1, очередь = 'com.apple.main-thread', причина остановки = EXC_BAD_ACCESS (код = 1, адрес = 0x0)

    • кадр # 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 =, баланс =) на vnl_determinant. hxx: 107 : 14 [opt]

      кадр # 2: 0x00000003dec807ac _ITKIOImageBasePython.so ___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252 frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so ___ lldb_un named_symbol7056 $$ _ ITKIOImageBasePython.so + 132

      кадр # 4: 0x00000003dec80586 _ITKIOImageBasePython.so ___lldb_unnamed_symbol9956$$_ITKIOImageBasePython.so + 38 frame #5: 0x00000003dea1d188 _ITKIOImageBasePython.so ___ lldb_un named_symbol1480 $$ _ ITKIOImageBasePython.so + 1560

      кадр # 6: 0x00000003ded50753 _ITKIOImageBasePython.so itk::ProcessObject::UpdateOutputInformation() + 351 frame #7: 0x00000003dec7fec2 _ITKIOImageBasePython.so ___ lldb_un named_symbol9945 $$ _ ITKIOImageBasePython.so + 70

      кадр # 8: 0x00000003ded5b6f4 _ITKIOImageBasePython.so itk::DataObject::Update() + 18 frame #9: 0x000000041a65c177 _ITKCommonPython.so ___ lldb_un named_symbol8759 $$ _ ITKCommonPython.so + 58

      кадр # 10: 0x000000010002c843 python _PyMethodDef_RawFastCallKeywords + 131 frame #11: 0x000000010002c1d6 python _PyObject_FastCallKeywords + 598

      кадр # 12: 0x0000000100164bb7 python call_function + 455 frame #13: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180

      кадр # 14: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532 frame #15: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403

      кадр # 16: 0x0000000100164aa7 python call_function + 183 frame #17: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180

      кадр # 18: 0x000000010002c535 python _PyFunction_FastCallKeywords + 229 frame #19: 0x0000000100164aa7 python call_function + 183

      кадр # 20: 0x000000010015cdb0 python _PyEval_EvalFrameDefault + 22144 frame #21: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532

      кадр # 22: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403 frame #23: 0x0000000100164aa7 python call_function + 183

      кадр # 24: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180 frame #25: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532

      кадр # 26: 0x00000001001c1afb python PyRun_FileExFlags + 235 frame #27: 0x00000001001c14c6 python PyRun_SimpleFileExFlags + 502

      кадр # 28: 0x00000001001ede30 python pymain_run_file + 160 frame #29: 0x00000001001ed72b python pymain_run_filename + 123

      кадр # 30: 0x00000001001ecf11 python pymain_run_python + 145 frame #31: 0x00000001001ecb8b python pymain_main + 27

      кадр # 32: 0x00000001000018c9 python main + 89 frame #33: 0x00007fff6aedfcc9 libdyld.dylib start + 1

      кадр # 34: 0x00007fff6aedfcc9 libdyld.dylib`start + 1

Может ли это быть связано с # 1168
https://github.com/SCIInstitute/ShapeWorks/issues/1168

-
Вы получаете это, потому что вас назначили.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/1179#issuecomment-807193351 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAJT3EKCRFSERHDJ5XDPHCDTFN2ZPANCNFSM4ZZUXDBQ
.

Обновлять. Хорошо, меня смутил вывод Python, я предположил, что он все еще находится на центральном шаге, так как дальнейшего вывода не было. В FindReferenceImage происходит сбой:

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

Я предполагаю, что проблема в том, что у нас есть две разные библиотеки ITK, загруженные в память. 👎

Давным-давно и далеко (эта ветка могла больше не существовать) я пытался построить привязки itk Python вместе с itk в build_dependencies, но мне это не удалось. Я подозреваю, что стоит еще раз попытаться, тем более что conda / pip, в частности, устанавливает разные версии некоторых, но не всех компонентов itk python (5.0 и 5.1), что является явным рецептом проблемы.

Я согласен, что может решить эту проблему, но как насчет # 1168. Нужно ли нам создавать itkwidgets с нуля и предоставлять его, чтобы он был построен с помощью нашего ITK?

Я согласен, что может решить эту проблему, но как насчет # 1168. Нужно ли нам создавать itkwidgets с нуля и предоставлять его, чтобы он был построен с помощью нашего ITK?

Если это проблема с общей библиотекой, возможно, мы можем установить LD_LIBRARY_PATH перед запуском записной книжки.
обновление: я пробовал это, и результат был таким же
update2: Я пробовал только вариант использования # 1168, а не этот.

В FindReferenceImage происходит сбой:

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

ShapeWorks не участвует в этом вызове. Интересно, можно ли очистить дополнительную информацию, запустив это через pdb :
python -m pub RunUseCase.py --use_case femur --groom_images (затем нажмите 'r' для запуска)

(Я использую это сейчас. Сколько времени требуется до сбоя? Кто-нибудь смог уменьшить это?)
update: это занимает много времени (~ час), но менее полезно то, что оно сообщает только об ошибке сегмента и даже не оставляет вас в отладчике. Я не вижу вызова внешних скриптов, поэтому меня это смущает.

Проблема, похоже, в том, что библиотека python ITK решает и вызывает нашу библиотеку VXL, а не ту, с которой она была построена:

  * 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

Напомним, что мы строим наш ITK с альтернативным VXL / VNL, а не с ITK. libvnl_algo.dylib - наш, _ITKIOImageBasePython.so - от conda.

Мы смешиваем разные версии, поэтому неудивительно, что он вылетает.

Мы с @archanasri просто попробовали
Я думаю, что решение проблемы # 1168 для нас - просто создать itkwidgets (сейчас мы пытаемся это сделать).
В этом случае можем ли мы указать itk на наш vnl как мы указываем его на наш eigen ?

У нас уже есть ITK, использующий наш VXL.

-DITK_USE_SYSTEM_VXL=on -DVXL_DIR=${INSTALL_DIR}

Обновлять. Хорошо, меня смутил вывод Python, я предположил, что он все еще находится на центральном шаге, так как дальнейшего вывода не было. В FindReferenceImage происходит сбой:

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

Я предполагаю, что проблема в том, что у нас есть две разные библиотеки ITK, загруженные в память. 👎

Вместо использования python itk мы можем использовать shapeworks.Image.toArray (). Поэтому я заменил

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

с участием

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

Теперь не вылетает.

Хороший @archanasri. Да, я подумал, что таким образом можно обойтись. По сути, нам нужно убедиться, что мы не используем python itk + our itk одновременно. Я думаю, что проблема itkwidgets - это более серьезная проблема, поскольку я предполагаю, что он использует интерфейс Python ITK внутри.

Да, и мы не можем создавать itkwidgets.
Нам нужно найти способ для itkwidgets использовать наш itk.

Да, и мы не можем создавать itkwidgets.
Нам нужно найти способ для itkwidgets использовать наш itk.

В itkwidgets 0.32.0 (последняя версия с тегами) setup.py он определяет следующие требования:

    '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',
    ],

Что касается itk, я думаю, это возвращает нас к созданию питона.
Другой способ приблизиться к этому - убедиться, что это версии, установленные pip (в основном) и conda.
Все версии в моей системе новее.

Вот что у меня есть:

(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

Один красный флаг - это версии 5.0.1 itk-io, -registration, -segmentation и, прежде всего, сам itk.

Я обновил установки пакета до последней версии (по какой-то причине мы не могли этого сделать, но пока отложим это) и перестроил все зависимости. # 1168 по-прежнему дает сбой, как описано в нем.

Фиксированный.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги