ITK/SimpleITK DICOM Series Loaded in wrong order / slice spacing incorrect

1.8k views Asked by At

The problem occurs with a number of the datasets, but we particularly noticed it with Soft-tissue-Sarcoma in the dicoms in

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

The spacing is read as 30 instead of 2.9 and the 3D image has brain slices between two lung slices

2

There are 2 answers

1
kmader On

Basically if you read the dicoms using SimpleITK.ReadImage or VTK the tool loads the files in the same order your list is in (usually alphabetical order). The mapping between the slices and the files are not in alphabetical order and are instead in a random order. This causes the Slice Spacing (a tag that is missing in these data) to be computed incorrectly since it is the difference in position between file 0 and 1. It also causes brain slices to turn up between two lung slices and other strange artifacts.

The solution is to presort the files using the GetGDCMSeriesFileNames function.

# 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)
4
malat On

So here is what I tried on my side:

$ 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

And then I check the output file with:

$ 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

Indeed you are right, GDCM computes the Z-Spacing as being 3.3 while it should really be 3.27 in this case. Please report a bug upstream.


Fixed in current git repository: