Operating system: Linux, Ubuntu 20.04
Slicer version: 4.11.20210226
Expected behavior:
When loading a DICOM database from the root folder, the order of the images is not inferred from (0020, 0013) Instance Number tag, however, when loading the first image in the series via the drag and drop functionality, the order is preserved.
Actual behavior: Not sure if this is expected behavior, since the discussion on ordering below indicates that the sorted images depend on having some geometry tags.
I do get the warning about this from this function:
Make sure you use the DICOM module to load DICOM images. That module uses the correct DICOM tags (image position patient, image orientation patient) to reconstruct the 3D volume. Instance number must not be taken into account when reconstructing a 3D volume from slices.
We have not disabled ITK’s limited DICOM image reader that can be accessed via the “Add data” dialog (or drag-and-dropping the first file to the application window), but that reader should not be used.
Thanks for the prompt response! I have been using the DICOM Module to load the image, but its possible the data I am using does not have the appropriate tags for orientation or pixel sizing.
When using the drag and drop, does this mean it is using ITK’s DICOM reader instead?
If so, then I guess ITK’s reader either uses the file name and/or Instance Number tag. Is this not recommended?
Since the order of the slices from the patient data I am using is missing the ones used by the DICOM module, would you suggest preprocessing to add the correct metadata to incorporate the correct tags? I am new to DICOM data, any advice would be appreciated!
ITK reader used to sort the files by default but then a few years ago the behavior changed, and I think you now always need to sort the files before passing it to the reader (ITK provides helper methods for that). In Slicer, we have not invested time into fixing up DICOM loading via the “Add data” dialog, so I think now this methods loads the files unsorted (uses whatever order the files are found on the file system).
Our plan is to intercept DICOM file loading in “Add data” and redirect that to the DICOM module, but this has not been implemented yet:
I’ve played around more with loading the data using the DICOM module, and the order is now preserved, when selecting the root folder with all patient/study/series data, but when loading one series individually, the order is not preserved:
./root/DICOM/PAT_0000/STD_0000/SER_00XY/OBJ_0001/
versus loading at the root
./root
in either case, the tag Pixel Spacing is not read properly.
Any thoughts on how to debug this? I assume its connected to the warning:
No geometry information available for DICOM data, skipping corner calculations
You can enable Detailed logging in Application settings → DICOM to get some more information, but I’m not sure if you get more details if basic geometry fields are invalid/missing.
Pixel Spacing is stored as a decimal string. If it is ignored then it is typically because the string is invalid (e.g., you write leading or trailing spaces, incorrect decimal separator, etc.).
DICOM standard is complex and it is hard to create valid images. One way to address this is to have a look at a valid DICOM image that is similar to what you want to create to see what fields are usually set. Then read description of each field in the DICOM standard to see how you should set them for your images.