enjoy-the-science/ohif-contour-tool

EARLY WIP

Goal

The goal of the project is to provide handy cornerstone tools for images segmentations.

Current tools:

Contour brush tool

Provides a simple brush tool which works in two conditions:

1. Creates segmentation if segmentation procedure started outside of segmentation region
2. Ereases segmentation if segmentation procedure started inside of segmentation region

Contour flood fill tool

Provides a flood fill algorithm for segmentation with threshold selection.

PencilML tool

Uses dextr algorithm to perform segmentation. The backend with running ML is in the separate repository

ohif-contour-tool's Issues

Предложения по части DevOps

Модель ветвления

git-flow хорош, но для небольших проектов он не нужен. Здесь гораздо легче применять упрощенную модель:

• Для каждой отдельной задачи создается новая ветка со ссылкой на Issue.
• После выполнения задачи создается PR и происходит ревью.
• После ревью и внесения всех правок ветка тащится в главную ветку разработки (можно даже master) по стратегии Squash and Merge, а затем удаляется.

Такая модель позволяет избежать обилия активных веток и большого количества коммитов в главной ветке разработки. Становится легче отслеживать изменения.

Работа с Issues

Этот раздел идет в связке с предыдущим. Давайте создвать Issue на каждый баг или улучшение, которое необходимо сделать, а затем назначать исполнителя как можно скорее.

Если задача большая, то можно создать Issue с чек-листом под базовую задачу, а затем отдельные Issue под каждый шаг ее выполнения, и в них вписать ссылку на базовую задачу.

Docker-образы

Давайте переберем Docker-образы для Viewer и бэкенда.

Сначала бэкенд:

• Dockerfile должен лежать в основной директории проекта. Это облегчает написание путей при сборке и деплое.
• Два Dockerfile на один проект точно не нужно. Если хочется разделить базовый и рабочий образы, можно использовать сборку под разные таргеты.
• Не нужно пихать конду в образ. Да, она удобна для разработки, но для деплоя и тестирования она бесполезна и только нагружает образ, увеличивая время сборки и пожирая больше ресурсов. Лучшая практика - использовать конду локально для разработки, а образ наследовать от обычного образа python и устанавливать зависимости через любой менеджер зависимостей (да хоть pip).
• Хардкодить зависимости в Dockerfile не нужно. Их лучше отдать менеджеру зависимостей. Я рекомендую poetry, но можно использовать и pip.

Насчет Viewer:

• Очень не нравится цельная Multistage сборка сразу с nginx. Можно разделить сборку на два таргета. Первый будет собирать и запускать nodejs-приложение, второй - настраивать nginx и соединять его с приложением из первого таргета через обратный прокси.
• Обе сборки можно соединять для интеграционного тестирования или продакшена через композ (см. следующую секцию). Это упростит развертку кластера в перспективе.

docker-compose

А давайте использовать docker-compose. Он избавит нас от необходимости собирать и запускать образы вручную и облегчит интеграционное тестирование. Можно поднять один нетворк для бэкенда и фронта, чтобы тестировать их вместе, если такая возможность потребуется.

CI

В Viewer уже есть конфиг для CircleCI, но мы его не используем. Там доступен бесплатный план на 2500 кредитов в неделю, что более чем достаточно для нас.

Шаги пайплайна:

• Build
• Test
• Publish (только на основной ветке)
• Deploy (только на основной ветке)

Джобы:

• Build - сборка нового docker-образа проекта. Шаг - Build.
• Code Health - проверка стиля кода. Для JS реализуется с помощью StandardJS и prettier-standard. Для питона - flake8, black, isort и mypy. Шаг - Test.
• Unit Tests - модульные тесты проекта. Шаг - Test.
• Integration Tests - интеграционные тесты проекта. Включают в себя тесты взаимодействия между компонентами и тесты сложных составных процессов. Выполняются с помощью docker-compose. Шаг - Test.
• Tag and Publish - постановка тега для последнего образа и docker push в репозиторий. Шаг - Publish.
• Deploy to Demo Server - развертка на демо-сервер с помощью Ansible. Шаг - Deploy.

База знаний и документация

Для написания доков и создания "базы знаний" можно использовать рабочий воркспейс (например Notion). Это позволит писать доки в удобоваримом формате (гораздо более удобном, чем Markdown), вести учет глобальных задач, структуры и текущего состояния проекта.

Дополнения и правки приветствуются

CI/CD

Внедрить систему деплоя (пересборки) вьювера при мерже в мастер

Интерфейс для работы с разметкой

WIP

Резюме: Интерфейс для выделения размеченнной области как сущности, комментарии, изменение её цвета, удаление сразу всего ROI, добавление комментариев к ROI.

Описание процесса интерфейса:
При сегментировании медснимков радиолог должен иметь возможность работать работать с сегментированной областью как единой сущностью. Например: на КТ-серии с 24-го по 32-снимок наблюдаются две отдельных опухоли: одна в районе сердца, другая – у стенки легкого.

Радиолог жмет элемент интерфейса: добавить ROI,
и сперва размечает первую опухоль, указвает ее тип

• nodule 􏰄>= 3 mm,
• nodule < 3 mm,
• non-nodule >= 3mm

и характеристики:

• subtlety...
• internal structure...
• spiculation...
• lobulation
• shape 􏰁sphericity􏰀
• solidity
• margin
• texture
• likelihood of malignancy

После завершения разметки первого из двух нодулей, радиолог переходит ко второму, повторяя всю процедуру.

Интерфейс позволяет удалить или отредактировать размеченную область.

Пример: https://www.cancerimagingarchive.net/viewer/?study=1.3.6.1.4.1.14519.5.2.1.6279.6001.269179928127536655796924146755&series=1.3.6.1.4.1.14519.5.2.1.6279.6001.270306633918898619338449637639&token=c20880b6-cf24-4fba-8ff0-3d2d8ee181ee

Динамика. Интерфейс

Интерфейс для удобного анализа серий одного и того же пациента в дигамике. В этой задаче два направления — сам интерфейс (e.g настройка полупрозрачности серий, наложение друг на друга) и

Оптимизация отрисовки сегментации

Проблема:
На снимках с большим разрешением попиксельный рендеринг готовых инструментов очень сильно тормозит. Сейчас большинство инструментов на маммографии (superresolution images: > 1024x1024) тормозит вплоть до 1-4 FPS

Необходимо решить задачу гладкой работы инструментов на снимках с любым разрешением.

Возможное решение: рендеринг только контуров. (попиксельная разметка → полигональные структуры данных. )

Pixel -> ROI -> VOI

TBD...

Linked with: #9

Задача
Изучить текущие структуры данных хранения и передачи сегментаций и предложить подходящую структуру, которая бы позволила:

1. оптимизировать объем передачи данных
2. возможность сечения в MPR в любой проекции

Предложить алгоритм конвертации пиксельной разметки в ROI (region of interest) и объединения ROI в VOI (volume of interest) после завершения разметки нодуля

PencilML tool optimization

Переписать Python-реализацию сети на TorchScript и подключить к существующему API. Возможно – поправить API.
(Текущая версия реализовывалась @scrat98 and @gohabereg)

Active contour tool

Дебаг, ресерч и внедрение.

(@ek_markova)

DEBUG: Contour fill tool

Ожидаемое поведение
Динамическая заливка узла без выпадений за пределы узла. Возможность отката.

Проблема
Нет возможности откатиться. Пропуски пикселей внутри залитой области. Иногда сильные выпадения за пределы узла.

DEBUG: Brush tool

Ожидаемое поведение
При отсутствии пиксельной разметки на слайсе:
• отрисовка

При наличии пиксельной разметки на слайсе:
• Курсор внутри разметки – отрисовка
• Курсор вне разметки – стирание.

Расчёт размерных характеристик VOI

Объем, максимальный диаметр

DEBUG: Contour brush tool. Wheel behaviour

Ожидаемое поведение:
Инструмент не выбран – колесо мыши прокручивает слайсы изображения
Инструмент выбран – колесо мыши увеличивает диаметр изображения. Выбранный до этого курсор (например contour fill) – исчезает. Остается только окружность.

Проблема:
Неконсистентное поведение колеса мыши при прокрутке: при при выборе инструмента иногда увеличивается диаметр, иногда прокручиваются снимки. Часто не исчезает курсор предыдущего инструмента.