Basically, the z spacing between slices are quite irregular, so when it was loaded, Slicer gave out a warning 0.6 spacing was expected, 0.5 spacing was found between files .
Assuming the 0.6 spacing between slices is correct, I used a dumb way to correct it because I could not find a better way online to correct the z spacing. Basically, I loaded slice i as ds0 and slice i +1 and ds1. I then update the z spacing of slice i+1 as the (z of slice i - 0.6) using ImagePositionPatient[2]:
The python snippet is here: test/test_py_dcm_2.py at main · chz31/test · GitHub. I also manually assigned a big space for slice 5, 105, and 205 according to the values of the space from the original dataset. I guess the skull was scanned in three separate sections then concatenate with each other since it is too large.
I printed out spacing_list to verify that the z spacing between slices is updated to 0.6 uniformly other than the large gaps at slice 5, 105, and 205. However, when I loaded the updated dicom to Slicer, I got more errors:
I’m new to dicom. I believe dicom data is not loaded following the alphabetic order of the dcm? The warning even suggested 0.3 andd 0.1 spacing was found. Could anyone give me some suggestions? Thanks!
You can read about how Slicer handles dicom with irregular spacing in this commit message and the module settings. Basically Slicer will create a grid transform to position the volume according to the ImagePositionPatient and ImageOrientationPatient and it should handle exactly the situation you describe. If you harden the transform, you’ll get a volume with equally spaced slices suitable for volume rendering and other tasks. The code that implements this is here.
Thank you! I’m playing with the code implements to see if I can use it to set a rule.
Meanwhile, just a naive question. I just loaded data that used the grid transform to change the volume with equally z space as 0.58, but the correct spacing should be 0.6. Can I just modify the z spacing in the Volumes module in 0.6? Or should I modify the target corners acquired from sliceCornersFromDICOM?
Since you are very familiar with this dataset by now it would be great if you could print out these corner locations and confirm that the dicom ones correspond with the ImagePositionPatient[2] values you set in your script and then look at the bounds of the resulting volume. It’s possible that the hardening step is using a different sampling grid than the original dicoms and that 0.58 is correct in the context of that grid (thus changing to 0.6 would change the aspect ratio and distort the volume). We might need a different sampling grid if you want 0.6 slice spacing.
The z positions of the raw images (raw_corners) & the ones I set up manually in my script are quite different from the ones I got from both originalCorners and targetCorners before and after grid transforms.
In the raw slices, there are large gaps between slices 5 and 6, slices 105 and 106, and slices 205 and 206 (-61, -116 and -116 respectively). When it was loaded, the z spacing between adjacent slices was all updated to 0.58:
This is indeed a very weird dataset. I felt like the scans were acquired 3 separate times and concatenated together. I suspected the slice below might show the poor concatenation
I’m not sure - to me that looks like the skull was glued back together. If it were a concatenation issue I’d expect a sharper discontinuity.
In the code you linked, self.sliceCornersFromDICOM(volumeNode) would be the list of per-slice corners in RAS where, if there is no rotation in the image orientation, the S value should match what you put in the ImagePositionPatient. The grid transform should be the mapping of the regularly-spaced image data such that each slice is moved to the correct spot as defined by the dicom tags by stretching the volume in the places where the spacing is larger.
Exactly! Some of these specimens have cut into calvaria (and old practice predating mCT to see internal structures). Because the bone is ground, they will not line up correctly. That’s probably a some sort of a clay or glue to keep the calvaria in place during the scan.
