Как записать несколько jpg-файлов в dicom-файл?

Question

[Александр Коробов]

Как записать несколько jpg-файлов в dicom-файл c помощью dcm4che?
Подскажите, хотя бы, последовательность действий для создания dicom-файла с multi-frame или multi-image серией.
А может я чего не понимаю? Может надо каждое изображение упаковывать в отдельный DICOM-файл и затем каждый DICOM-файл отправлять на PACS?

Answer 1

[pi314]

Для multiframe примерно так:

- создать BasicDicomObject, в заголовке которого:
- наполнить метаданные для patient/study/series, уникальные идентификаторы и пр. лабуду,
- не забыть выставить modality в SC (secondary capture),
- указать фотометрические данные изображения (разумеется, они должны быть идентичны для всех вставляемых фреймов) и тайминг (количество, длительность, рекомендованный DisplayFrameRate и т.д.)

Это будут необходимые метаданные. Для записи всей этой кухни в файл:

- создать нужный ImageWriter, которому дать стрим для нужного файла,
- инициировать запись последовательности (prepareWriteSequence), начав с метаданных,
- потом продолжать записывать отдельные фреймы, при необходимости перекодируя/масштабируя изображения в нужный формат.

Потом закрыть стрим и наслаждаться результатом.

П.С. Про танцы с бубном вокруг кодеков, цветовых профилей и компресси с/без потерь и про то, как отправлять в PACS, распространяться не буду, т.к. если пишете в DICOM, то наверняка и сами в курсе, а если еще нет, то впереди Вас ждет много интересного и увлекательного )) Но, в любом случае, мой Вам совет - для уменьшения количества седых волос забудьте про DCM-файлы и смотрите в стророну передачи по сети... тем более, что в dcm4che очень хорошая и удобная имплементация всего, что для этого нужно. А еще там в комплекте где-то есть готовые консольные утилитки, делающие всю эту и другую магию, так что подробности можно посмотреть в их исходниках. По поводу, собственно, записи multiframe файл можно еще глянуть вот сюда.

Comments

[Александр Коробов]

Большое спасибо за Ваш ответ.
Занимаюсь данным вопросом несколько дней. Голова идет кругом. Вопросов много, а ответов пока нет. Общего видения пока нет.

С Вашего позволения, задам еще несколько вопросов:
1) Суть задачи - сохранять изображения с мед. эндоскопа в уже развернутый PACS-сервер. Изображений этих до десятка. Может и не надо никакой мультифрейм? Какой, для этой задачи, подход выбрать, на Ваш взгляд?
2) Если имеются ссылки на информацию, которыми не жалко поделиться, пожалуйста, поделитесь?

Премного благодарен.

[Александр Коробов]

Вот в группе гугл подсказали-

If you need to group multiple images into one series, you'd need to create multiple dicom files (one for each image), each with the same Study Instance UID, the same Series Instance UID and differen SOP Instance UIDs (i.e. the image's UID). You should be able to send the Dicom files in any order, and a good PACS should be able to group them, based on the UIDs.

Теперь все работает, как надо.

[pi314]

Александр Коробов, Так и нужно же было начинать с того, что речь идет об эндоскопе! Хорошо, конечно, что заработало, но все равно многое остается непонятным. Прежде всего, почему тогда JPEG (а не, как минимум, JPEG2000 lossless)??? Смысл медицинских изображений в том, чтоб гарантированно донести их без искажений цветопередачи от снявшей матрицы камеры через всю цепочку до глаза врача, проводящего диагностику - для этого и придуман такой сложный DICOM. Отправлять в PACS изображения, полученные из JPEG, можно только в виде SC (secondary capture), а от медицинского эндоскопа, вообще-то, ожидается ES, т.е. изображение без потерь и с корректными фотометрическими метаданными. Такое изображение можно использовать для диагностики, а secondary - только в качестве сопроводительной информации. А иначе велик риск по такой "диагностике" случайно отрезать ногу, вместо того, чтоб пришить руку ))

Далее, о multiframe и серии. Это, собственно, совершенно разные вещи. Серия, это набор статических изображений (т.н. stills), полученных в процессе одного конкретного исследования, т.е. в одно время, с одним и тем же пациентом, врачем и т.д. Обычно эндоскоп работает так, что перед началом исследования оператор вводит все данные (или эндоскоп сам получает их из MWL), а потом нажимает на кнопку камеры и делает несколько нужных снимков. Вот они и есть серия. Их метаданные, кроме уникального ID, будут отличаться только точным временем создания и номером в серии. Такие изображения врач рассматривает по-отдельности.

А multiframe обычно используется для секвенций изображений, которые имеет смысл рассматривать в динамике - либо во времени, как, например, US (УЗИ), либо в пространстве, как, например CT/MRT (томографы, сканирующие слой за слоем... в этом случае принципиально важно знать, какой слой на отдельном изображении). Еще современные эндоскопы умеют снимать настоящее видео, но это тогда все равно не JPEG, a MPEG2/MPEG-4, и это, вообще, мало кому нужно и в реальной жизни крайне редко используется.

На всякий случай: серия отличается oт исследования (study) тем, что в одном исследовании может быть много разных серий от разных устройств. В описанном случае речь, конечно же, идет о серии, но JPEG там нечего делать - только несжатые изображения или компрессия без потерь! А изображения, хоть однажды сжатые JPEG, строго говоря, уже не являются медицинскими, т.е. пригодными для диагностики, и в реальный PACS, обычно, даже редко принимаются.

Далее самое главное - подозрение насчет того, откуда мог взяться JPEG: некоторые тупорылые маркетологи заставляют разрабов встраивать даже в очень хорошие эндоскопы всякие вредоносные свистелки типа, "раз есть картинки, давайте заодно будем жать их в JPEG и откладывать на сетевую шару или FTP". В результате это приводит к тому, что когда в конкретной клинике возникает необходимость отправлять изображения в PACS, обычно, под рукой не находится кого-то, способного разобраться с непонятным монстром DICOM (хотя любой сертифицированный медицинский эндоскоп умеет это из коробки просто по определению!), и вопрос "решается" нахождением кого-то, кто с помощью dcm4chee или аналогичных штук перепакует привычные и понятные JPEG-картинки и зафигачит их в PACS. Искренне надеюсь, что у Вас не такой случай, но если вдруг, то учтите, что это практически уголовное преступление.

Далее, о "сохранении в PACS". Стандарт DICOM состоит из многих частей, среди которых и часть, описывающая протоколы передачи. Нормальный способ, это передача по сети, при которой PACS и модалити сначала договариваются обо всех подробностях, а потом передают, собственно, изображения. "Передача" через DCM файлы, это хоть и очень популярный и распространенный, но все равно костыль. Фактически, в таком файле записан DICOM стрим, который бы передавался по сети, но там есть ряд ограничений и часто это работает очень криво.

Для беглого ознакомления с DICOM могу порекомендовать блог Рони, одного из разработчиков RZDCX. Это имплементация высокоуровнего DICOM SDK под .Net, но это не так важно, т.к. там очень хорошо и доступно описаны именно основы DICOM. Ну, а детали, конечно, нужно искать в самом первоисточнике.

[Александр Коробов]

...но если вдруг, то учтите, что это практически уголовное преступление.

Это что фигура речи такая?

...а secondary - только в качестве сопроводительной информации...

Пока, что это действительно так.

Про multiframe и серии уже мало-мальски разобрался. Но спасибо.

Далее, о "сохранении в PACS". Стандарт DICOM состоит из многих частей...

Понял уже, что с наскока не получится.

...любой сертифицированный медицинский эндоскоп умеет это из коробки просто по определению...

Спасибо. Этот момент я уточню.

JPEG2000 lossless

Про эту штуку можно подробнее.

...такой сложный DICOM...

Ох, блин!

Answer 2

[private_tm]

jpeg to dicom java в гугл

Вот один из примеров
https://stackoverflow.com/questions/21087778/how-t...