Update gdcm

[hjmjohnson]

Release 3.0.24 COMP: Fix for gcc13.2 compiler test failures Another pass for SIEMENS/MOSAIC Check for Secondary Capture spacing following DICOM Part 3 Sect A.8.1.3

PR Checklist

• [X] No API changes were made (or the changes have been approved)
• [X] No major design changes were made (or the changes have been approved)

[seanm]

This caused another behaviour change in our application's test suite...

We have a test that reads a single DICOM file (just one slice) with GDCMImageIO. With the resulting itk::Image we call GetSpacing() and now we get 5.0 for the z spacing instead of the 1.0 we got before with PR.

Since it's just one slice, I'm not really sure if 1 or 5 is the right answer.

I've built GDCM master, and gdcminfo also gives 1, so I'm not sure where the 5 is coming from...

[seanm]

@thewtex @malaterre @hjmjohnson so we looked at this more... it seems the behaviour has only changed when there is just 1 DICOM slice.

So before this PR, with either 1 or 2 files in the folder, we get:

spacing: {0.661468, 0.661468, 1.0}

After this PR, with 1 file we get:

spacing: {0.661468, 0.661468, 5.0}

but with 2 files we get:

spacing: {0.661468, 0.661468, 1.0}

Is this a deliberate change? BTW the file we are using is D_CLUNIE_CT1_J2KR.dcm, which is in the GDCM test suite.

[thewtex]

@seanm there is a flag that needs to be passed to gdcminfo to get the additional metadata, --scipm

[seanm]

@thewtex thanks for your reply! So without --scipm:

Spacing: (0.661468,0.661468,1)

and with --scipm:

Spacing: (0.661468,0.661468,5)

Interesting. OK, so this explains differences using gdcminfo I guess.

But we're using ITK. We use itk::ImageSeriesReader / itk::GDCMImageIO and the result is different between ITK 5.3 and 5.4 (for the case of 1 file in the folder). Perhaps some sample code will help, see attached, it's only 70 lines. DICOMReader-Single_vs_MultiFile-Series.zip

What we're trying to understand is if this behaviour change between ITK 5.3 and 5.4 is deliberate / correct / buggy.