BUG: Regression for scans with negative spacing in DICOM #7987
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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.