Комментарии 26
Впечатляющая работа!!!
+4
а погонять эту программу можно?
0
С удовольствием бы почитал про обращение преобразования Радона с точечным источником и о реализации этого всего с использованием CUDA
+6
Извините, не понял. Это ваш продукт или вы сделали эту прогу для кого то? Сколько стоит сам томограф и прога к нему?
+1
Вот это вещь! Ролики впечатлили. Интересно, а разглядеть что изображено под слоем «сотри и выиграй» лотерейного билета на нем можно?
+5
Мде интересно, а лотерейные билеты (которые ногтем тереть) эта машина просветит? Там же должен быть рельеф?
+1
Забавный hivemind у вас и товарища выше.
+3
Отличие в плотности цифр под слоем минимальная, рентген не возьмёт. тем более их как раз и разрабатывали в том числе и для того чтобы нельзя было просветить рентгеном. Структура билетиков многослойная и в каждом слое свой мусор, который не отличается материалом от самих цифр — на фоне этого мусора на рентгеновском снимке надпись просто не будет видно.
И ещё, я бы предположил что краска которую надо стирать меняет цвет после рентгена. Это было бы логичным шагом.
И ещё, я бы предположил что краска которую надо стирать меняет цвет после рентгена. Это было бы логичным шагом.
+2
Спасибо :(
Что ж… значит придется по старинке: запираться в сортире с светящим мобильником и пультом от теле. Долго-долго смотреть… обычно после женщины в красном что-то, да проглядывает через черную краску.
Что ж… значит придется по старинке: запираться в сортире с светящим мобильником и пультом от теле. Долго-долго смотреть… обычно после женщины в красном что-то, да проглядывает через черную краску.
0
Томограмма могла бы побороться с многослойностью, будь разрешение достаточным
0
У меня есть сомнения на этот счёт. Эти билетики делают специально чтобы было трудно просвечивать, куда не ткни, а луч вынужден проходить множество неоднородностей из такого же материала как и сама надпись. С какой стороны леса не посмотри, а на опушку в глубине леса никак не посмотришь.
0
Решили подобную задачу (для большого томографа) в 2000 году. Отличие — пациент облучался не 360 раз, а 4. По 4 снимкам восстанавливали трехмерную картинку исходя из принципа максимальной энтропии. Решали методом Метрополиса. Изоповерхность строили так же, но вокселов не знали, картинки были статичные, строились медленно.
+6
Подробности есть? В продакшн пошло? За снижение лучевой нагрузки все томографостроители борятся же!
0
Заказчик — медицинская контора из Бостона. Проект в рамках МНТЦ. На нас было лишь R&D. Про конечный железный продукт ничего не могу сказать.
0
Алгоритмы насколько выкуплены и защищены? Есть право / возможность выложить в open source? Хотя бы в виде статьи с формулами?
0
Ну не все же борятся. Есть ведь медицина, а есть промышленность.
Ближайший аналог того томографа, что в статье, это, к примеру Phoenix Nanotom, он в серийном продакшене:
![image](https://habrastorage.org/r/w780q1/getpro/habr/comment_images/774/a6e/2e0/774a6e2e0ea538b47e68e114b661f673.jpg)
У него паспортное разрешение до 0,2 микрона, но, правда и стоимость соответствующая. Вот видео
На самом деле алгоритмы реконструирования сами по себе хорошо известны и относительно несложные, однако дьявол кроется в деталях — если применять их «в лоб», то мы получим артефакты преобразования (в виде концентрических окружностей, полос, и т.п.) и довольно большая часть не кода не столько сама реконструкция, сколько борьба с артефактами. Ну и стабильность железа важна — зачастую всё монтируют на монолитной гранитной плите, ставят подшипники на воздушной подушке, термостабилизированный детектор, встроенный кондиционер и всё такое.
Ближайший аналог того томографа, что в статье, это, к примеру Phoenix Nanotom, он в серийном продакшене:
![image](https://habrastorage.org/getpro/habr/comment_images/774/a6e/2e0/774a6e2e0ea538b47e68e114b661f673.jpg)
У него паспортное разрешение до 0,2 микрона, но, правда и стоимость соответствующая. Вот видео
На самом деле алгоритмы реконструирования сами по себе хорошо известны и относительно несложные, однако дьявол кроется в деталях — если применять их «в лоб», то мы получим артефакты преобразования (в виде концентрических окружностей, полос, и т.п.) и довольно большая часть не кода не столько сама реконструкция, сколько борьба с артефактами. Ну и стабильность железа важна — зачастую всё монтируют на монолитной гранитной плите, ставят подшипники на воздушной подушке, термостабилизированный детектор, встроенный кондиционер и всё такое.
0
Фантастика.
0
Здорово, просто молодцы. Хотя у меня по ходу чтения появилось немножко вопросов.
Камера, которую вы использовали (PIXIS-XF надо полагать) отдаёт картинки 2048х2048, а в статье вы пишете «до 8000х8000». Это вы как получили? Вы перемещаете также образец или камеру по вертикали и горизонтали и склеиваете потом картинки?
Демо изображения, которые в видео в конце статьи — они все получены из 360 проекций? Если так, то это хорошо, ведь 360 проекций с шагом в градус — довольно мало, обычно идут с шагом треть/четверть градуса, иначе будут артефакты реконструкции. Вроде есть формула оптимального количества проекций для заданного разрешения, но вот запамятовал.
Ещё я не очень понял про частоту камеры. По спецификации она двухчастотная на 100 килогерц или два мегагерца. Если у неё четыре мегапиксела — это значит, что она отдаёт кадр каждые две секунды на максимальной частоте?
Вы перемещаете манипулятор пошагово или непрерывно? Сколько времени занимает сканирование типичных образцов, что представлены на видео?
Ну и про 12 бит — очень любопытно. Ну, то что отрезать четыре бита и упаковать каждые два пиксела в три байта можно для хранения и передачи — это понятно. Но для реконструирования вам же придётся снова развернуть каждый пиксел как минимум в два байта? Или у вас вся математика на 12-ти битах — в этом случае как вы решили проблему того, что пикселы занимают полтора байта и не выравниваются на границу?
Спасибо.
Камера, которую вы использовали (PIXIS-XF надо полагать) отдаёт картинки 2048х2048, а в статье вы пишете «до 8000х8000». Это вы как получили? Вы перемещаете также образец или камеру по вертикали и горизонтали и склеиваете потом картинки?
Демо изображения, которые в видео в конце статьи — они все получены из 360 проекций? Если так, то это хорошо, ведь 360 проекций с шагом в градус — довольно мало, обычно идут с шагом треть/четверть градуса, иначе будут артефакты реконструкции. Вроде есть формула оптимального количества проекций для заданного разрешения, но вот запамятовал.
Ещё я не очень понял про частоту камеры. По спецификации она двухчастотная на 100 килогерц или два мегагерца. Если у неё четыре мегапиксела — это значит, что она отдаёт кадр каждые две секунды на максимальной частоте?
Вы перемещаете манипулятор пошагово или непрерывно? Сколько времени занимает сканирование типичных образцов, что представлены на видео?
Ну и про 12 бит — очень любопытно. Ну, то что отрезать четыре бита и упаковать каждые два пиксела в три байта можно для хранения и передачи — это понятно. Но для реконструирования вам же придётся снова развернуть каждый пиксел как минимум в два байта? Или у вас вся математика на 12-ти битах — в этом случае как вы решили проблему того, что пикселы занимают полтора байта и не выравниваются на границу?
Спасибо.
+2
Смотрелку сохранённого воксельного массива не хотите выложить в исходниках и сделать расширяемой энтузиастами? А то все они убогие и закрытые…
0
Коллеги, ответы на вопросы можно почитать в новой статье: Подробнее о разработке софта рентгеновского томографа.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как за 5233 человеко-часа создать софт для микротомографа