Серия ITK/SimpleITK DICOM загружена в неправильном порядке/неверное расстояние между слоями

Проблема возникает с рядом наборов данных, но мы особенно заметили ее с Soft- тканевая саркома в дикомах в

STS_004/1.3.6.1.4.1.14519.5.2.1.5168.1900.124239320067253523699285035604/1.3.6.1.4.1.14519.5.2.1.5168.1900.952127023780097934747932279670

Расстояние читается как 30 вместо 2,9, а на трехмерном изображении есть срезы мозга между двумя срезами легких.


python imaging dicom itk
person kmader    schedule 08.12.2016    source источник
comment
VTK был помечен, так как похожая проблема возникла здесь   -  person kmader    schedule 09.12.2016

Ответы (2)


arrow_upward
1
arrow_downward

По сути, если вы читаете дикомы с помощью SimpleITK.ReadImage или VTK, инструмент загружает файлы в том же порядке, в котором находится ваш список (обычно в алфавитном порядке). Отображение между фрагментами и файлами не в алфавитном порядке, а в случайном порядке. Это приводит к тому, что расстояние между срезами (тег, отсутствующий в этих данных) вычисляется неправильно, поскольку это разница в положении между файлами 0 и 1. Это также приводит к тому, что срезы мозга появляются между двумя срезами легких и другие странные артефакты.

Решение состоит в предварительной сортировке файлов с помощью функции GetGDCMSeriesFileNames.

# noinspection PyPep8Naming
import SimpleITK as sitk

def safe_sitk_read(img_list, *args, **kwargs):
    dir_name = os.path.dirname(img_list[0]) 
    s_img_list = sitk.ImageSeriesReader().GetGDCMSeriesFileNames(dir_name)
    return sitk.ReadImage(s_img_list, *args, **kwargs)
person kmader    schedule 08.12.2016
comment
Я считаю, что GDCMImageIO поступает правильно. Также GetOrigin не Slice Location насколько я знаю. - person malat; 09.12.2016

arrow_upward
0
arrow_downward

Итак, вот что я пробовал на своей стороне:

$ gdcm2vtk --lower-left --ipp-sort STS_004/1.3.6.1.4.1.14519.5.2.1.5168.1900.124239320067253523699285035604/1.3.6.1.4.1.14519.5.2.1.5168.1900.952127023780097934747932279670 /tmp/kmader.mha

И затем я проверяю выходной файл с помощью:

$ head -13 /tmp/kmader.mha 
ObjectType = Image
NDims = 3
BinaryData = True
BinaryDataByteOrderMSB = False
CompressedData = False
TransformMatrix = 1 0 0 0 1 0 0 0 1
Offset = -250 -250 -5
CenterOfRotation = 0 0 0
ElementSpacing = 0.976562 0.976562 3.3
DimSize = 512 512 311
AnatomicalOrientation = ???
ElementType = MET_SHORT
ElementDataFile = LOCAL

Действительно, вы правы, GDCM вычисляет Z-Spacing как 3,3, тогда как в этом случае на самом деле должно быть 3,27. Пожалуйста, сообщите об ошибке вверх по течению.

Исправлено в текущем репозитории git:

person malat    schedule 09.12.2016
comment
Спасибо, я предполагаю, к сожалению, что может пройти еще очень много времени, прежде чем пакеты python отобразят обновления для GDCM, поэтому тем временем потребуются небольшие взломы. - person kmader; 09.12.2016
comment
@kmader GetOrigin возвращает индекс в трехмерном пространстве. Вы, кажется, берете 1-ю координату. Это не сработает, если вы используете другое направление для приобретения. Кроме того, Slice Location — это опциональный порядок, определяемый поставщиком (возможно, не связанный с 3D-пространством). - person malat; 09.12.2016
comment
есть ли лучшее решение, использующее SimpleITK внутри python? или мне нужно вручную вытащить последнюю основную ветку, скомпилировать gdcm2vtk, выполнить ее в списке, а затем прочитать MHA? - person kmader; 09.12.2016
comment
Я бы использовал один из примеров из SimpleITK напрямую. например, itk.org/SimpleITKDoxygen/html/ - person malat; 09.12.2016