Hi Slicers, I am writing a python script to convert from DICOM to NRRD so I am going through the different DICOM headers and I am calculating the Image Origin of my T2W volume.
After sorting the list of DICOM slices according to the projections in the slice direction (using ImageOrientationPatient and ImagePositionPatient) I get an order that I can verify with the SliceLocation header (So I know I have ordered them correctly to form a consistent volume).
So now, I take the ImagePositionPatient header of the first slice in the volume and I have
[-57, -65, 24] which corresponds to the information I get for the first slice of the volume when I check with HOROS (So basically I confirm again that I have the correct order)
However when I open the same DICOM volume in Slicer I get a slightly different Image Origin:
What is the reason for this?
I am not sure how slicer shows the Image Origin OR if I am correct in assuming it will coincide with the ImagePositionPatient of the “first” slice in the volume (as per the ordering method described here).
I appreciate any help!
Thanks,
Diego
UPDATE
I think I answered my own question. Notice the position of the sliders in the two tools. The first slide in HOURUS corresponds to the last slide in Slicer. I checked and the values actually match, so it is a matter of how I order the stack of slices. Horus orders the stack in the superior->inferior order where as slicer goes inferior->superior in the coronal slice.
Question 1: How is this decided?
Question 2: why do I get [57, 82, -27] in Slicer and I get [- 57, - 82, 27] for the ImagePositionPatient header in the correct slice? (correct as in the matching the slice in both tools)
Is Slicer reporting the origin in RAS already?
I would assume so but could anyone please confirm?
Slicer delegates this to ITK. As I recall depending on the method used to read it may enforce a right-handed orientation matrix so it may reorder the data to match.
In general, slice indexes do not matter and may be quite random for certain imaging modalities and 4D sequences. So, most 3D software (which operates on reconstructed 3D volumes instead of just showing 2D image slices) do not keep track of which pixel generated from which combination of slices. If you need to find slice index corresponding to a coordinate then you have to go back to the Slicer DICOM database and search the slice based on image position patient and image orientation tags.
Hi Steve, I checked again and it does work on Chrome but it shows those error messages on Firefox and Safari. My browsers are up to date (latest versions on OS X High Sierra).
I am writing my own code to convert DICOM to NRRD, the question I have at hand right now is to generate the appropriate space dimensions tag in the NRRD header from the information contained in the Image OrientationPatient and ImagePositionPatient in DICOM.
I think I am almost done with this problem. I need to know what was the first slice in the DICOM series (and yes I can see that they are not ordered and the lexicographic order of the series does not guarantee the order in the volume). So I think I already solved it: I take the ImagePositionPatient of the first slice (after ordering the slices in space) as the value for the space dimensions NRRD header.
The second part of the question (which I believed Steve addressed) was the conversion from LPS to RAS, So I basically need to change the signs appropriately to reflect the origin in RAS coordinates.
I hope this makes sense. Is there anyone here with experience in this type of code? Who wrote it in ITK?
Oh, no… Why would you even consider doing this? This is so much more complicated than you would think. So many people have spent years implementing the current DICOM image readers (ITK, vtkDICOM, GDCM, etc) and you can see that the results are still so much limited. Instead of starting from scratch with a DICOM image reader, it would make much more sense if you contributed to existing implementations with bugfixes or improvements.
I am realizing that now. I don’t think it is complex per se but the problem is the many possible combinations and making sure your reader handles all the possible cases correctly. So it is laborious and you could say it’s almost combinatorics problem.
I wanted to avoid ITK compilation but I think it’s currently available as any other pip package in Python? so that would solve my problem.
Concerning the coordinate system web site, can you test again - I tried chrome, safari, firefox, (all on mac) and edge on windows and it looks fine. There was a mathml problem a couple weeks ago but it should be fixed now.
Also following up on the ITK/Slicer etc DICOM reading, since there are so many possible ways to map DICOM data to things of interest in Slicer (not just image data, but reports, segmentations, transforms, etc) we have a Plugin mechanism were different readers can take responsibility for different data.
Within the ScalarVolume reader, we first use this consistency check code linked below and then provide the files to ITK pre-sorted (I don’t know if it is still the case but at one point ITK got the image origin from the first file in the list we provided).
Thank you for the information Steve. I think I am going to try and read my DICOM series with ITK and save them as NRRD in ITK. I haven’t done it but I imagine this is pretty straightforward with an image reader and an image writer. Also, can you confirm that I don’t need to compile ITK with CMake as in preivous years but now I can just download the python wrapper as a pip package?
