Комментарии 15
Во-вторых, с учетом того, что исследования обычно имеют размер примерно 512х512х512 вокселей, размер памяти, требуемой для хранения результатов сглаживания, в среднем будет занимать около 5 Гб. Чтобы сократить количество расходуемой памяти мы воспользовались пирамидой (scale space pyramid).
Не вполне понимаю, каким образом сократили расход памяти? Неужели древообразная ссылочная структура с листовыми узлами на разных уровнях? Мне это не кажется хорошим решением — ссылки сами по себе занимают объём, дико фрагментируют память и т.д.
Мы разрабатывали т.н. "блочные модели" для геологии (по сути, тот же 3D массив). Расход памяти там сокращается за счёт своей системы поблочного свопинга и сжатия данных быстрыми алгоритмами. Пирамида только ускоряет обработку данных, но не особо сокращает расход памяти.
использование пирамиды таит в себе очень много трудностей и проблем, с которыми мы столкнулись, и которые тянут на отдельную статью, если про них рассказывать.
Есть такое) Не так страшна реализация пирамиды, как реализация алгоритмов на ней.
Не вполне понимаю, каким образом сократили расход памяти?Пирамида нужна только для хранения результатов сглаживания. Грубо говоря, если сделать в лоб, то нужно памяти: sizeof(float)*512x512x512 (для сглаживания с sigma1) + sizeof(float)*512x512x512 (для сглаживания с sigma2) +… + sizeof(float)*512x512x512 (для сглаживания с sigma10). Ответ там же:
Идея заключается в том, что раз уж после каждого сглаживания значения интенсивности в соседних вокселях размываются и становятся примерно равными, то нет смысла хранить их все. Т.е. чем больше sigma, тем меньше нам потом потребуется просчитанных вокселей, чтобы восстановить сглаживание по всему объему.В самой пирамиде все хранится по аналогии с рисунком без всяких тонкостей: для sigma1 512х512х512, для sigma2 256х256х256, для sigma3 128х128х128 и т.д. Т.е. сокращение памяти идет за счет того, что само сглаживание имеет некоторые особенности. Scale space pyramid — довольно стандартное решение, можно посмотреть в интернете/википедии. Сжатие самих данных — это уже следующий шаг, но он не потребовался.
А, ясно. Вы сокращаете память с n*sizeof(float)*512^3 (n>1, n in Z) до (8/7)*sizeof(float)*512^3. Я подумал, что с sizeof(float)*512^3 до величины, меньшей этого значения.
Делаем небольшой шаг в направлении сосуда и попадаем в новый воксель
Если пользователь отмечает две точки сосуда, то вы можете методом поиска кратчайшего пути найти весь сосуд между ними. Это ещё решит проблему с "разрывами" сосудов. Мы подобное делали на сходных объёмах данных, правда в 2D изображениях.
Может быть будет возможно отказаться от сглаживания гауссианами, я так понимаю, что сосудистость резко возрастает к центру, а алгоритму поиска пути только и нужно, чтобы сосуд резко выделялся на фоне. Тогда линия пойдёт ровно по центру.
Мы по изображению считали индекс похожести на дорогу, а затем искали путь минимальной стоимости между двумя точками.
![](https://habrastorage.org/webt/1k/s9/kp/1ks9kpaxvtqu9qpchsi9wvdcmbm.jpeg)
![](https://habrastorage.org/webt/qr/vb/uc/qrvbucn13z-qt_jw5fwd0068sqe.jpeg)
![](https://habrastorage.org/webt/h5/ib/za/h5ibzahchowljjreqj9unuhqowc.jpeg)
houdinigubbins.wordpress.com/2017/07/22/fiedler-vector-and-the-medial-axis
Решение проблемы обнаружения центральной линии сосуда