Behaviour change between ITK 5.3 and 5.4 with DICOM spacing

[seanm]

Further to some discussions in #4647 and #4521, we still have a situation that isn't quite clear to us, and since those are merged already, we thought we'd create a new ticket.

Basically, there is a change in behaviour between ITK 5.3 and 5.4 that we are trying to understand if it's a bug or deliberate & correct.

If we query a DICOM file for its image spacing information, we get different results depending on:

• using itk::ImageSeriesReader vs using itk::GDCMImageIO
• having 1 DICOM file in the folder vs having multiple

A small C++ test case is attached: inconsistency_in_spacing.zip

It uses a DICOM file named D_CLUNIE_CT1_J2KR1.dcm, from the GDCM test suite I think, but from David Clunie's collection ultimately I suppose.

In ITK 5.3:

Number of files	ImageSeriesReader	GDCMImageIO
Single	[0.661468, 0.661468, 1]	[0.661468, 0.661468, 1]
Multiple	[0.661468, 0.661468, 1]	[0.661468, 0.661468, 1]

Notice everything agrees: the z spacing is 1.

In ITK 5.4 / master:

Number of files	ImageSeriesReader	GDCMImageIO
Single	[0.661468, 0.661468, 5]	[0.661468, 0.661468, 5]
Multiple	[0.661468, 0.661468, 1]	[0.661468, 0.661468, 5]

Notice now everything does not agree.

The change from 1 to 5 is presumably deliberate from #4521.

But then shouldn't that lone 1 (in the bottom left) also be 5?

Thanks.

[issakomi]

The behavior change may probably be related to these lines introduced in the commit malaterre/GDCM@836f7a7. In fact ImageHelper::SecondaryCaptureImagePlaneModule variable seems to affect the several MediaStorage classes above, maybe there should be logic + break before? I don't know. Even if I am on the list of co-authors, I didn't make
the change, we started with very simple proposal https://github.com/InsightSoftwareConsortium/ITK/pull/4120/files. If I remember correctly this particular change was done by the GDCM owner, but I am not sure.

BTW, the 'Multiple' series is just duplicated file, both with the same Instance UID (this is invalid) and z-spacing is just a matter of fallback (it is 0 or undefined).

[issakomi]

I mean:

FYI, I will not do any PRs or other actions related to this issue

Edit: if it is still not clear: this looks for me as a fall-through bug in switch, the value of ImageHelper::SecondaryCaptureImagePlaneModule (hard-coded to true in GDCM IO) should not affect other IODs.

[issakomi]

https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913 may be related

[thewtex]

CC @dclunie