Hi I am trying to read CT scan dicom series using Simple ITK ImageSeriesReader() In order verify each image slice I also load the CT scan in osirix image viewer. After reading from series reader when I load sample slices from 3D image I observed that slice 0 actually represents last Image in Osirix image viewer. Is the reading order reversed? Thanks Jiten
Slices in ITK are ordered by their image position patient tags. I don’t know how OsiriX orders them.
You might also be interested in this explanation.
Here is an example on how to read a DICOM image series in SimpleITK:
If you have more than one DICOM series in the directory you may need to use sitk:ImageFileReader:: GetGDCMSeriesIDs.
Thanks @dzenanz this is great information. Once the information is read by ITK series reader, Can we sort the order by Z of the image and then rewrite it? Thanks, Jiten.
Thanks @blowekamp I did write the code to read the series from the link you sent. In the use case I am solving we will get only one series, but I will keep note of this info when I bump into use case that would have multiple series. Thanks Jiten.
Note that one of the voxel (IJK) coordinates often looks similar to DICOM slice (instance) number (for example, you may find that instance number = k+1 or N-k+1), but you cannot rely on this. Each application can decide how it defines voxel coordinates. Only physical (LPS) coordinates and DICOM slice numbers are guaranteed to be consistent between applications.
If you need to compute DICOM slice number then you can read image position, image orientation, and instance number tags for each DICOM slice and use this to find a slice corresponding to a a physical (LPS) point position.
Thanks @lassoan. Based on given information, I would not mess with the image that is read by simpleITK from series. Instead I can easlily tweak my logic to read it the way ITK has read the series into image. Thanks, Jiten
I have the same problem and based on this discussion it’s still not clear why this happens and what is the right way to enforce consistency here. @Jigabytes compared the order with Osirix viewer. I checked the RadiAnt DICOM Viewer, MicroDICOM they all show slices in opposite order comparing to Simple ITK.
But most important part - the itk-js gives the opposite order!
This is really confusing. And the most important question I have here is not even why, but when it happens? Is it a constant thing and to enforce the consistency I should just always reverse the first axis of a numpy array after reading? Or should I look at some DICOM tags to figure out if Simple ITK will produce the reversed array?
I assume here you are using SimpleITK in Python and that you are obtaining the content of the image as a numpy array from the SimpleITK image?
SimpleITK and numpy indexing access is in opposite order:
For examples see this Jupyter notebook section titled “Conversion between numpy and SimpleITK”.
If this is not addressing your issue, please clarify. Note that there are two potential issues: (1) the data is in a reversed/unexpected order (2) display of the data is in reversed/unexpected order. Identifying which issue you are dealing with will help us resolve your problem.
Your other assumptions are correct. The numpy array is built using
readImageDICOMFileSeries method and then convert to tf.tensor:
var tensor = tf.tensor(image.data. It works and I can reed the data. But on z axis the data goes in different order on JS and Python.
tensor.slice([0, 150, 300], [1, 5, 5]) gives same data as
src_array[-1, 150:155, 300:305].
This just seems to be different conventions between itk-js and SimpleITK-Python.
import SimpleITK as sitk import itk import numpy as np file_name = "head_mr_oriented.mha" itk_array = itk.GetArrayFromImage(itk.imread(file_name)) sitk_array = sitk.GetArrayFromImage(sitk.ReadImage(file_name)) print(np.sum(np.abs(itk_array - sitk_array)))