Incorrect Orientation in SPECT DICOM Multi-frame Reconstructions

[VipeRub]

Description

I'm currently working on NM SPECT images and I have encountered an issue with dcm2niix when converting certain NM multi-frame DICOM images. Specifically, I have observed that some reconstructed images from GE workstation are flipped upside-down during the conversion process. This issue seems to occur with DICOM files where:

• the ImageType (0008,0008) Value 3 is equal to "RECON TOMO" or "RECON GATED TOMO";
• the SpacingBetweenSlices (0018,0088) tag has a negative value.

As described in the DICOM standard (C.8.4.15 NM Reconstruction Module) : "The sign of the Spacing Between Slices (0018,0088) determines the direction of stacking. The normal is determined by the cross product of the direction cosines of the first row and first column of the first frame, such that a positive spacing indicates slices are stacked behind the first slice and a negative spacing indicates slices are stacked in front of the first slice." I performed some tests by changing the DICOM tags, but could not get the image correctly oriented as a result of dcm2niix. Here there is an image of the converted NIFTI:

Thank you for your support.

Output log The DICOM files I converted have ImageType equal to [DERIVED,PRIMARY,RECON TOMO,EMISSION] , so the dcm2niix log returns some warning messages:

DICOM file: ./TOMO_.dcm
 patient position (0020,0032)   -224.372    -224.372    256.937
 orient (0020,0037) 1   0   0   0   1   0
 acq 0 img 2 ser 85 dim 128x128x128x1 mm 3.53342x3.53342x3.53342 offset 100760 loc 128 valid 1 ph 0 mag 0 nDTI 0 3d 0 bits 16 littleEndian 1 echo 0 coilCRC 0 TE 0 TR 0
Warning: Patient Position (0018,5100) not specified (issue 642).
Converting ./TOMO_.dcm
Warning: Unable to determine slice direction: please check whether slices are flipped (derived image)
Convert 1 DICOM as ./_XXXXX (128x128x128x1)
Conversion required 0.024043 seconds (0.008335 for core code).

Version

Chris Rorden's dcm2niiX version v1.0.20241024 GCC7.5.0 x86-64 (64-bit Linux)

I found this issue with the latest stable release ( v 1.0.20240202) and the latest commit in the development brach

[neurolabusc]

This sounds like a limitation of your DICOM images, not dcm2niix. I note your data is DERIVED and if you check the provenance of your images and get the ORIGINAL images I suspect all will be fine. I have seen many tools that generate derived data that assume the results are for visual inspection only. I suspect the problem is that you do not get a different Image Position Patient (0020,0032) per frame. This is a Type 1 (required) tag for original data. Beyond explicitly coding slice direction, this tag is also crucial for determining distance between slice centers, which also describes why SpacingBetweenSlices (0018,0088) is unreliable.

You can check my hypothesis by running:

dcmdump +P "0020,0032" TOMO_.dcm

[VipeRub]

Thank you for the prompt reply and for the detailed explanation. You’re absolutely right and this is indeed a limitation of the DICOM images generated by the GE workstation. unfortunately, I can't always get the ORIGINAL images. In these reconstructed images, there is only a single Image Position Patient (0020,0032) value: the frame ordering is described in the Slice Vector (0054,0080) tag rather than by individual positions per frame, while the sign of the SpacingBetweenSlices is used to determine the direction of stacking. Is there an option within dcm2niix to have the converted image automatically flipped to correct the orientation in cases like these?

[neurolabusc]

@VipeRub feel free to make a fork to implement your request, and submit a pull request (to the development branch) if you want to share it. However, this should method should only be applied if each slice does not have Image Position Patient (0020,0032). A couple of major caveats apply:

• Image Position Patient (0020,0032) is a type 1 required tag. dcm2niix assumes the DICOM images are valid and truthful. This assumption is not met for your data - it is not archival quality and will likely fail other tools designed for the specification. I would encourage you to check the provenance of your images to understand why they are invalid.
• Be aware that Slice Vector (0054,0080) is type 1C, meaning they are only required in specific conditions, and seems peculiar to nuclear medicine (I do not remember every seeing this tag for MR).
• As noted manufacturers have been inconsistent in their interpretation of Spacing Between Slices (0018,0088). As I recall, it has been used with different interpretations by GE hardware, so even knowing the manufacturer may not be specific. It is an optional, rather than required tag, so you can not rely on the presence of this tag.

Therefore, from my perspective this is a limitation of your images not dcm2niix. dcm2niix correctly detects that this series is underspecified. Creating kludges to handle underspecified data does open the door to unintended consequences.