Bugfixes in DCMTK

[maekclena]

The first commit fixes #1125 and removes an outdated comment.
The second commit adds a metadata read for spacing (according to already existing comments in the code) to fix failing test itkDCMTKImageIOMultiFrameImageTest.

PR Checklist

• 🚫 Makes breaking changes
• 🚫 Makes design changes
• 🚫 Adds the License notice to new files.
• 🚫 Adds Python wrapping.
• 🚫 Adds tests and baseline comparison (quantitative).
• 🚫 Adds test data.
• 🚫 Adds Examples to ITKExamples
• 🚫 Adds Documentation.

[dzenanz]

I remember some discussions about this, e.g. #112 and #315. Were you aware of it @maekclena?

[maekclena]

No, I did not know. It seems like the fallback behavior was mistakenly removed in #243.

[hjmjohnson]

No, I did not know. It seems like the fallback behavior was mistakenly removed in #243.

I don't think it was mistakenly removed. My recollection is that it was purposefully removed because using SliceThinkness was determined to be the wrong approach. If 0018, 0088 is not present, then the correct behavior is to explicitly compute the distance between slices as described in

#112 (review)
and
#112 (comment)

@malaterre is an expert in DICOM conformance.

[hjmjohnson]

Earlier discussions state that using 0018,0050 is a dangerous and incorrect way of determining z-spacing. This code was purposefully removed previously.

[dzenanz]

Please split this into two PRs. First commit is non-contentious, and can be merged immediately. That will allow reviews for the second commit independently.

[malaterre]

No, I did not know. It seems like the fallback behavior was mistakenly removed in #243.

I don't think it was mistakenly removed. My recollection is that it was purposefully removed because using SliceThinkness was determined to be the wrong approach. If 0018, 0088 is not present, then the correct behavior is to explicitly compute the distance between slices as described in

#112 (review)
and
#112 (comment)

@malaterre is an expert in DICOM conformance.

1. 0018,0088 is Spacing Between Slices and should represent the actual Z-spacing when present,
2. Never (ever!) confuse Spacing Between Slices and Slice Thickness those are totally independent attributes
3. During the course of ITK dev, it was found that Spacing Between Slices may be missing (eg. CT Image Storage), or incorrect. Computing the actual Z-spacing from the IOP & IPP make sure to report any missing slices or inconsistency. Which is the reason why it is acceptable to loop over all frames to (re)compute the Slice Interval.

Ref:

• https://stackoverflow.com/a/15116116/136285

[dzenanz]

The contentious changes have been removed. And disabling the failing test is reasonable.

[dzenanz]

I think we should squash when merging.