GDCM ignores image geometry in secondary captures

[pieper]

Description

Secondary capture images can optionally have ImageOrientationPatient and PixelSpacing fields, but GDCM currently forces the orientation to identity and looks for NominalScannedPixelSpacing instead of PixelSpacing, so otherwise valid images are loaded incorrectly.

There is more information in the discussion at this PR:

Slicer/Slicer#7089

Steps to Reproduce

The data available from the idc-open-data set on aws is the Visible Human Project male dataset converted to dicom by @dclunie.

You can get one file with this command:

aws s3 cp --no-sign-request s3://idc-open-data/4aaf9181-fb6a-4a4c-bf49-d1eb9ed4a385/fbc89e1c-29c4-48cf-89fd-53b7c1dc1488.dcm .

Or the whole dataset using this command (about 13 gigabytes).

s5cmd --no-sign-request --endpoint-url https://s3.amazonaws.com cp 's3://idc-open-data/4aaf9181-fb6a-4a4c-bf49-d1eb9ed4a385/*' .

Expected behavior

The index to physical transform should be correctly populated.

Actual behavior

The direction cosines are explicitly set of identity:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx#L731-L740

The PixelSpacing is ignored, and the NominalScannedPixelSpacing is looked for, but is typically absent.

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx#L1265-L1273

Reproducibility

Always

Versions

Tested on current main branch, but I suspect the code has been around for decades.

Environment

Any

Additional Information

I'll probably fix this, although it may not be a high priority if we fix #4108 instead.

[dclunie]

@issakomi I have asked @malaterre to reopen and implement the referenced PR, and uploaded to the PR a copy of a proposed DICOM CP specifying the behavior.

[issakomi]

Thank you very much for your attention to the problem.

[malaterre]

As stated elsewhere, you already have a mechanism in place directly in ITK to handle any extension you like:

• Kitware@168c457

As stated also elsewhere, you could be totally backward compatible with all the existing tools out there, if only you had used the right SOP Class : 1.2.840.10008.5.1.4.1.1.7.4 [Multi-frame True Color Secondary Capture Image Storage]

• ENH: Handle IPP/IOP/PixelSpacing for SC malaterre/GDCM#158 (comment)

[malaterre]

Secondary capture images can optionally have ImageOrientationPatient and PixelSpacing fields, but GDCM currently forces the orientation to identity and looks for NominalScannedPixelSpacing instead of PixelSpacing, so otherwise valid images are loaded incorrectly.

This is what I read with my version of dciodvfy(*). Just implement your private extended SOP Class directly in ITK.

(*)

$ dciodvfy 000198cd-cd88-4760-97d1-21bbea047fff.dcm
[...]
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x0088) DS Spacing Between Slices
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x0032) DS Image Position (Patient)
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x0037) DS Image Orientation (Patient)
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x0052) UI Frame of Reference UID
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x1040) LO Position Reference Indicator
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x1041) DS Slice Location

[malaterre]

One last rant before I stop on the subject. This PR requires first a CP to the current DICOM 2023c edition:

• ENH: Handle IPP/IOP/PixelSpacing for SC malaterre/GDCM#158 (comment)

[dclunie]

Since @malaterre has decided not to be helpful, we will need to work around his recalcitrance in ITK as he suggests.

[malaterre]

Since @malaterre has decided not to be helpful, we will need to work around his recalcitrance in ITK as he suggests.

Yeah right. 20 years in maintaining GDCM summarized because I disagree with you.

[dclunie]

Your long history of valuable contributions is not undermined by one deviation.

[thewtex]

Closed via #4521