DICOM volume converted to NIfTI as a series with both hemispheres

[ghisvail]

Hi Chris,

Describe the bug

I have a DICOM consisting of a single brain volume acquired with a spoiled gradient echo sequence on a GE scanner. After successful conversion, the resulting NIfTI volume contains a series consisting of two half-volumes covering each hemisphere instead of a single volume.

To reproduce

1. Download and unzip the DICOM dataset in the zip below (I got authorization for sharing).

T13D.zip

2. Run dcm2niix -z y . inside the DICOM folder.

The logs should display:

Chris Rorden's dcm2niiX version v1.0.20211006  Clang13.0.0 x86-64 (64-bit MacOS)
Found 164 DICOM file(s)
Convert 164 DICOM as output/_PROT_FATEB_20050331144342_4 (256x256x82x2)
Conversion required 2.092806 seconds (1.995564 for core code).

Take notice of the dimensions parsed by dcm2niix (256x256x82x2) versus the actual ones (256x256x164).

3. Open the DICOM volume and resulting NIfTI file with Mango.

The DICOM file is rendered properly as a single volume.

The NIfTI file is detected as a series of 2 volumes.

Output log

log.txt

Version

dcm2niiX version v1.0.20211006 Clang13.0.0 x86-64 (64-bit MacOS)

Let me know if you need further information or if I missed something.

Cheers,
Ghis

[neurolabusc]

@mr-jaemin can you help me resolve this? This is an example of a ZIP2 acquisition.

Typically we detect ZIP2 using two conditionals:

1. Both the private tag LocationsInAcquisitionGE (0021,104f) and public tag (0054,0081) must exist, yet have different values.
2. Both the public tags SliceThickness (0018,0050) and SpacingBetweenSlices (0018,0088) must exist, yet have different values. The ratio is the ZIP factor.

The issue with the data from @ghisvail is that the tag LocationsInAcquisition is not present in the dataset. Due to this, dcm2niix assumes the data is not ZIP2, and assumes that any discrepancy between 0018,0050 and 0018,0088 reflect a spatial gap between neighboring slices.

Here are the relevant tags from this series:

(0008,0020) DA [20050331]  #   StudyDate
(0008,103e) LO [Obl T1 3D FSPGR IR preped]  #  SeriesDescription
(0008,1090) LO [SIGNA EXCITE]  # ModelName
(0018,1020) LO [11]  # SoftwareVersions
(0021,104f) SS 82  #  LocationsInAcquisitionGE
(0018,0050) DS [2]  # SliceThickness
(0018,0088) DS [1]  # SpacingBetweenSlices
(0054,0081) MISSING # LocationsInAcquisition

This series would be correctly converted if we relax the ZIP2 detection removing the conditional:

(d.locationsInAcquisition > 0)

But I suspect this would have widespread unintended consequences for non-ZIP2 images where a slice gap is present. To my eye, this looks like an old dataset using a very old GE software version. Is there any trick to robustly detecting ZIP2?

@ghisvail dcm2niix aspires to convert all DICOMs, regardless of the acquisition. I presume this is a very early implementation of ZIP2, and it is unclear if we can automatically detect this without profound consequences to correctly specified DICOM images. If this is a one-off conversion of archival data, I would suggest patching dcm2niix as I describe above to handle this unusual data. As ever, when planning new acquisitions, I would always recommend not artificially interpolating data to a higher resolution (e.g. ZIP2). From my perspective, this artificially increases disk requirements, slows processing and is incompatible with some post processing.

[neurolabusc]

@mr-jaemin perhaps one solution would be to detect ZIP2 if SliceThickness
is greater than SpacingBetweenSlices. Typically, adding a gap results in an acquisition where slice thickness is thinner than the spacing between slice centers (to avoid cross talk). So an acquisition where the thickness is larger than the distance between slices (overlap, rather than gap) is pretty unusual (as it would typically incur interference).

[ghisvail]

As always, thank you very much Chris for your prompt replies.

I understand the challenges on your end, please take your time to work on a proper fix. Meanwhile I'll compile a custom version with the fix you suggested for converting this specific dataset.

As ever, when planning new acquisitions, I would always recommend not artificially interpolating data to a higher resolution (e.g. ZIP2).

Sadly, we have no control over the exam protocol which produced this dataset.

[pvelasco]

So an acquisition where the thickness is larger than the distance between slices (overlap, rather than gap) is pretty unusual (as it would typically incur interference)

It is pretty unusual, true, but one could do it to increase SNR (having thicker slices than without overlap); if the slice excitation time between overlapping slices is long enough, there would be no cross-talk.

[mr-jaemin]

One solution would be to read GE Protocol Data Block (0025,101B), particularly "IOPT". This data includes "ZIP2" string as shown below:

ENTRY "Head First"
POSITION "Supine"
COIL "HEAD"
PLANE "OBLIQUE"
SEDESCFLAG "1"
SEDESC "Obl T1 3D FSPGR IR preped"
IMODE "3D"
PSEQ "SPGR"
IOPT "Fast, IrP, ZIP2"
PLUG "6"
MONSAR "y"
IEC_ACCEPT "OFF"
FILTCHOICE "C"
BWRT "-1"
TAG_SPACE "7"
TAG_TYPE "None"
USERCV6 "0.00"
USERCV_MASK "64"
FLIPANG "10"
TE "Minimum"
NECHO "1"
TI "400"
AUTOTRGTYPE "0"
AUTOTRIGWIN "0"
FOV "30"
SLTHICK "2.0"
SLABLOC "86"
OVLPLOC "0"
GRXOPT "0"
SLOC1 "R83.9"
SLOC2 "A6.4"
SLOC3 "I0.6"
ELOC1 "L78.0"
ELOC2 "A0.6"
ELOC3 "I0.6"
NOSLC "1"
MATRIXX "224"
MATRIXY "224"
SWAPPF "S/I"
NEX "2.00"
CONTRAST "No"
CONTAM "No    "
TBLDELTA "0.00"
PHASEFOV "0.80"
RBW "15.63"
AUTOSHIM "Yes"
PHASECORR "No"
AUTOCF "Water"
PAUSEDELMASKACQ "1"
AUTOSUBOPTIONS "0"
AUTOSCIC "0"
TOTALNOSTATION "0"
STATION "0"

[neurolabusc]

@ghisvail can you test out the latest commit to the development branch, I think it resolves this issue. I added a new check that counts the number of times a spatial position is repeated in a dataset. If this does not match the number of volumes in the dataset and the data is from GE, it will determine if ZIP2 can resolve the issue. If there is still a conflict, a warning is generated. This is a more generalized solution than what @mr-jaemin suggested, and can help detect other errors.

@ghisvail do you have the bandwidth to help with updating the MRIcron Debian release to the latest version and supporting QT5 (vs GTK2)? I have been delaying releasing v1.2.20211006 until this is resolved. If you are too busy, I can send a request to the Debian medical team.

[ghisvail]

Le jeudi 11 novembre 2021 à 05:07 -0800, Chris Rorden a écrit :

@ghisvail can you test out the latest commit to the development branch, I think it resolves this issue. I added a new check that counts the number of times a spatial position is repeated in a dataset. If this does not match the number of volumes in the dataset and the data is from GE, it will determine if ZIP2 can resolve the issue. If there is still a conflict, a warning is generated. This is a more generalized solution than what @mr-jaemin suggested, and can help detect other errors.

Sounds good. I can test that and report tomorrow.

@ghisvail do you have the bandwidth to help with updating the MRIcron Debian release to the latest version and supporting QT5 (vs GTK2)? I have been delaying releasing v1.2.20211006 until this is resolved. If you are too busy, I can send a request to the Debian medical team.

The team is pretty busy at the moment, myself included. I could aim for some time in December.

[ghisvail]

can you test out the latest commit to the development branch, I think it resolves this issue.

I confirm it does 👍

Thank you so much Chris!