Небольшое исследование об отображении кириллического текста в dicom-элементах типа Code String (CS). Не всё так просто, как оказалось. Инструкцию читать надо! :)

Один из пользователей программы Dicom AutoExport версии 1.9.1 прислал несколько файлов с указанием того, что кириллица в тегах такого типа все-равно неправильно отображается после конвертации.

Что выяснилось? А оказалось, что тип кодировки, указанный в элементе (0008,0005) совершенно не влияет на отображение символов в элементах Code String. 

В стандарте (https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html) он определяется как строка символов длиной не более 16 байт, которая может содержать прописные буквы, цифры 0-9, пробел и нижнее подчеркивание.  Кодировка символов в стандарте не указана, но вот на одном из сайтов нашёл, что она должна быть ASCII, понятно что латиница:
https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/dicom/user-attributes.htm . Откуда они взяли, что должно быть именно ASCII непонятно, но, по-видимому, многие вьюверы ожидают именно её.

Взял, что было под рукой из вьюверов. Оказалось, что это Microdicom, weasis и Радиант. Dicom-файл "сделан" на аппаратуре и ПО компании Телеоптик, программой экспорта кодировка всех текстовых тегов, в том числе и CS, конвертирована в UTF-8.

Microdicom и weasis однозначно не опознают здесь УТФ8.
То, что там УТФ я убедился через онлайн-конвертер.

MD Weasis UTF8

А Радиант нормально всё видит.

readiant utf8

Есть ещё один нюанс.
DicomDump указывает, что ошибка также в том, что значения тегов взяты не из словаря, т. е. не соответствуют стандарту.

DicomDump 

 

Например, для (0018,5101) это должны быть двух-трехбуквенные значения, обозначающие позицию пациента: https://dicom.innolitics.com/ciods/cr-image/cr-series/00185101

А для (0018,0015) есть приложение L в стандарте с перечислением возможных значений: https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html#chapter_L

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

Начал экспериментировать. Взял аналогичные файлы, где все теги в кодировке 1251 и всё, кроме CS конвертировал в UTF-8. Т.е. (0018,0015) и (0018,5101) остались в кодировке win-1251.

Теперь MicroDicom все отображает корректно:

2 MD

 А Weasis все-равно не понимает кириллицу в CS:

2 weasis

 И Радиант перестал правильно смотреть:

2 radiant

Т.о. вывод:
Первый вьювер в этих тегах читает кодировку в вин-1251, второй — непонятно, что ждет, а Радиант ждет то, что указано в (0008,0005).

 Добавил функцию конвертации из 1251-ansi в ascii и применил ее только к тегам CS.
Т.е. всё в UTF-8, а CS в ASCII
Теперь MicroDicom показывает какую-то хрень, а точнее пытается ascii отобразить как 1251:

3 md

Weasis все равно кириллицу не видит:

3 weasis

И Радиант тоже:

4 radiant

Вывод: Нет одного единого подхода у вьюверов при отображении этих тегов. Единственный вариант, когда все вьюверы не отображают иероглифы в этих тегах — латиница. Т.е., чтобы всех удовлетворить, нужно CS записывать латиницей, а ещё лучше конкретные значения брать из словаря.
Для (0018,5101) в «людской» рентгенографии это всего-то восемь возможных значений: AP, PA, LL, RL, RLD, LLD, RLO, LLO. Для ветеринарии, конечно, посложнее :) и для лаборанта там вообще китайская грамота будет. Но, наверное, стоит эти значения жестко занести в список для выбора без возможности его редактирования.
Для (0018,0015) всё ещё сложнее. Укладок хренова туча и все их проблематично внести. А если даже они и будут доступны для выбора, то кто же их выбирать будет, когда мало кто из персонала смыслит в этих названиях. Когда укладка выбирается на графическом шаблоне, то лаборанты ещё справляются как-то, а выбрать из списка непонятных слов на латинице — это нереально :)

В версии 1.9.3 программы Dicom AutoExport была добавлена для элементов типа Code String была специально добвлена опция, определяющая, каким образом их обрабатывать. 

 

Добавить комментарий