BUG: Regression for scans with negative spacing in DICOM #7987
Conversation
Fixes Slicer#7937 See original report here about a dataset being scrambled that loaded well in the 5.6.2 release: https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913 This corresponds to the change in behavior described here, where spacing from ITK that used to be 1 is now, for example 5 or -1: InsightSoftwareConsortium/ITK#4794 Which is believed to be due to the changes here, which was added so that for Secondary Capture files the spacing would be respected if present: InsightSoftwareConsortium/ITK#4521 However adding this code in GDCM meant that if the SpacingBetweenSlices tag is present, even in a CT, it is being used by ITK to calculate spacing, and also ITKToRAS transforms when trying to orthogonalize the transform. Since Slicer doesn't rely on orthogonal IJKToRAS transforms, this change tells ITK to skip that step and instead it relies on the positions and orientations of the slices to calculate the IJKToRAS transform, which is compatible with what Slicer expects. This code was tested on both the CT scan with the negative spacing that was reported in the original issue, and on other CT cans without that tag and the geometry matches what was obtained in 5.6.2. This change was discussed in the Slicer developer meeting 2024-10-08 and determined to be the best course of action. Further fixes in GDCM or ITK were not pursued because it was unclear whta the correct behavior should be at the library level considering that a negative spacing between slices is technically invalid for CT scans according to the DICOM standard.
|
Thanks Slicer team for your work on this! I wanted to ask about something -- in the case where the SpacingBetweenSlices=5, but the actual difference in z-axis position in the image files (per ImagePositionPatient) is, say, 2.5, the image will be loaded with slice width of 2.5, right? However, in that case, do we have any idea why/how SpacingBetweenSlices would be set to 5? My reading of the standard is that if it is present, it should agree with what is computed from ImagePositionPatient. But I currently am working with some CTs from GE scanners where that doesn't seem to be the case for some reason. |
|
The image is loaded with slices in the correct physical position, based on |
Fixes #7937
See original report here about a dataset being scrambled that loaded well in the 5.6.2 release:
https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913
This corresponds to the change in behavior described here, where spacing from ITK that used to be 1 is now, for example 5 or -1:
Which is believed to be due to the changes here, which was added so that for Secondary Capture files the spacing would be respected if present:
However adding this code in GDCM meant that if the SpacingBetweenSlices tag is present, even in a CT, it is being used by ITK to calculate spacing, and also ITKToRAS transforms when trying to orthogonalize the transform.
Since Slicer doesn't rely on orthogonal IJKToRAS transforms, this change tells ITK to skip that step and instead it relies on the positions and orientations of the slices to calculate the IJKToRAS transform, which is compatible with what Slicer expects.
This code was tested on both the CT scan with the negative spacing that was reported in the original issue, and on other CT cans without that tag and the geometry matches what was obtained in 5.6.2.
This change was discussed in the Slicer developer meeting 2024-10-08 and determined to be the best course of action. Further fixes in GDCM or ITK were not pursued because it was unclear whta the correct behavior should be at the library level considering that a negative spacing between slices is technically invalid for CT scans according to the DICOM standard.