search

rordenlab / dcm2niix

dcm2nii DICOM to NIfTI converter: compiled versions available from NITRC
https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage
Other
878 stars 228 forks source link

converting mp2rage INV/INV2/UNI images #536

Closed ccn30 closed 3 years ago

ccn30 commented 3 years ago

Describe the bug

Many thanks for this amazing software! Head's up I'm not an expert in neuroimaging. This isn't a bug but something I'm stuck with.

I need to perform MP2RAGE reconstruction using separate INV1,INV2 and UNI images with the RobustCombination().m function from https://github.com/JosePMarques/MP2RAGE-related-scripts

For each image series per INV1/2/UNI, dcm2niix does not convert images of equal array dimensions that I need and produces the following output.

Output log

Chris Rorden's dcm2niiX version v1.0.20210317 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.4.0 x86-64 (64-bit Linux) Warning: only processing last of 224 input files (recompile with 'myEnableMultipleInputs' to recursively process multiple files) Found 224 DICOM file(s) Slices not stacked: some are phase/real/imaginary/phase maps, others are not. Instances 208 114 Warning: Interslice distance varies in this volume (incompatible with NIfTI format). Warning: Missing images? Expected 221 images, but instance number (0020,0013) ranges from 1 to 224 Convert 221 DICOM as /rds/project/rds-URQgmO1brZ0/p00500/ENCRYPT_images_raw/32663/20210826_U-ID53508/Series_006_MP2RAGE_0.7_INV1/Series_006_MP2RAGE_0.7_INV1_MP2RAGE_0.7_20210826131924_6 (320x320x221x1) Unable to equalize slice distances: slice order not consistently ascending: dx=[0 0 0.699997 1.4 2.1 2.8 3.5 4.2 4.9 5.6 6.3 7 7.7 8.4 9.1 9.8 10.5 11.2 11.9 12.6 13.3 14 14.7 15.4 16.1 16.8 17.5 18.2 18.9 19.6 20.3 21 21.7 22.4 23.1 23.8 24.5 25.2 25.9 26.6 27.3 28 28.7 29.4 30.1 30.8 31.5 32.2 32.9 33.6 34.3 35 35.7 36.4 37.1 37.8 38.5 39.2 39.9 40.6 41.3 42 42.7 43.4 44.1 44.8 45.5 46.2 46.9 47.6 48.3 49 49.7 50.4 51.1 51.8 52.5 53.2 53.9 54.6 55.3 56 56.7 57.4 58.1 58.8 59.5 60.2 60.9 61.6 62.3 63 63.7 64.4 65.1 65.8 66.5 67.2 67.9 68.6 69.3 70 70.7 71.4 72.1 72.8 73.5 74.2 74.9 75.6 76.3 77 77.7 78.4 79.8 80.5 81.2 81.9 82.6 83.3 84 84.7 85.4 86.1 86.8 87.5 88.2 88.9 89.6 90.3 91 91.7 92.4 93.1 93.8 94.5 95.2 95.9 96.6 97.3 98 98.7 99.4 100.1 101.5 102.2 102.9 103.6 104.3 105 105.7 106.4 107.1 107.8 108.5 109.2 109.9 110.6 111.3 112 112.7 113.4 114.1 114.8 115.5 116.2 116.9 117.6 118.3 119 119.7 120.4 121.1 121.8 122.5 123.9 124.6 125.3 126 126.7 127.4 128.1 128.8 129.5 130.2 130.9 131.6 132.3 133 133.7 134.4 135.1 135.8 136.5 137.2 137.9 138.6 139.3 140 140.7 141.4 142.1 142.8 143.5 144.2 144.9 145.6 146.3 147 147.7 148.4 149.1 149.8 150.5 151.2 151.9 152.6 153.3 154 154.7 155.4 156.1 0 2.35432e-41 0 5.19969e-19 1.55698e-41 5.19969e-19 1.55698e-41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5.20101e-19 1.55698e-41 -nan 0 4.30479e-39 0 4.59177e-39 0 7.39818e-38 0 -nan -nan 5.45273e-39 0 7.39819e-38 0 0 0 6.31369e-39 0 6.60068e-39 0 -nan 0 7.17465e-39 0 7.46163e-39 0 5.19278e-19 1.55698e-41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1.17664e-38 0 1.20534e-38 0 1.23404e-38 0 1.26274e-38 0 1.29144e-38 0 1.32014e-38 0 1.34883e-38] Recompiling with '-DmyInstanceNumberOrderIsNotSpatial' might help. Warning: Interslice distance varies in this volume (incompatible with NIfTI format). Warning: Missing images? Expected 3 images, but instance number (0020,0013) ranges from 114 to 177 Convert 3 DICOM as /rds/project/rds-URQgmO1brZ0/p00500/ENCRYPT_images_raw/32663/20210826_U-ID53508/Series_006_MP2RAGE_0.7_INV1/Series_006_MP2RAGE_0.7_INV1_MP2RAGE_0.7_20210826131924_6_ph (320x320x3x1) Unable to equalize slice distances: slice order not consistently ascending: dx=[0 0 21.7 44.1 1.55698e-41 7.39168e-38 0 4.62428e-44 0 0 0 2.86986e-40 0 5.73972e-40 0 3.93723e-41 0 5.19969e-19 1.55698e-41 5.19969e-19 1.55698e-41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5.20101e-19 1.55698e-41 -nan 0 8.51989e-43 0 0 0 7.39185e-38 0 -nan -nan 8.40779e-43 0 7.39186e-38 0 0 0 8.32371e-43 0 8.29569e-43 0 -nan 0 8.23963e-43 0 8.21161e-43 0 5.19278e-19 1.55698e-41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7.79122e-43 0 7.76319e-43 0 7.73517e-43 0 7.70714e-43 0 7.67912e-43 0 7.65109e-43 0 7.62306e-43 0 7.59504e-43 0 7.56701e-43 0 7.53899e-43 0 7.51096e-43 0 7.48293e-43 0 7.45491e-43 0 7.42688e-43 0 7.39886e-43 0 7.37083e-43 0 7.3428e-43 0 7.31478e-43 0 7.28675e-43 0 7.25873e-43 0 7.2307e-43 0 7.20267e-43 0 7.17465e-43 0 7.14662e-43 0 7.1186e-43 0 7.09057e-43 0 7.06254e-43 0 7.03452e-43 0 7.00649e-43 0 5.19208e-19 1.55698e-41 3.85651e-41 0 5.19969e-19 1.55698e-41 5.19969e-19 1.55698e-41 0 0 0 0 6.81031e-43 0 6.78228e-43 0 6.75426e-43 0 6.72623e-43 0 6.69821e-43 0 6.67018e-43 0 6.64215e-43 0 6.61413e-43 0 6.5861e-43 0 6.55808e-43 0 6.53005e-43 0 6.50202e-43 0 6.474e-43 0 6.44597e-43 0 6.41795e-43 0 6.38992e-43 0 6.3619e-43 0 6.33387e-43 0 6.30584e-43 0 6.27782e-43 0 6.24979e-43 0 6.22177e-43 0 6.19374e-43 0 6.16571e-43 0 6.13769e-43 0 6.10966e-43 0 6.08164e-43 0 6.05361e-43 0 6.02558e-43 0 5.99756e-43 0 5.96953e-43 0 5.94151e-43 0 5.91348e-43 0 5.88545e-43 0 5.85743e-43 0 5.8294e-43 0 5.80138e-43 0 5.77335e-43 0 5.74532e-43 0 5.7173e-43 0 5.68927e-43 0 5.66125e-43 0 5.63322e-43 0 5.60519e-43 0 5.57717e-43 0 5.54914e-43 0 5.52112e-43 0 5.49309e-43 0 5.46506e-43 0 5.43704e-43 0 5.40901e-43 0 5.38099e-43 0 5.35296e-43 0 5.32493e-43 0 5.29691e-43 0 5.26888e-43 0 5.24086e-43 0 5.21283e-43 0 5.1848e-43 0 5.15678e-43 0 5.12875e-43 0 5.10073e-43 0 5.0727e-43 0 5.04467e-43 0 5.01665e-43 0 4.98862e-43 0 4.9606e-43 0 4.93257e-43 0 4.90454e-43 0 4.87652e-43 0 4.84849e-43 0 4.82047e-43 0 4.79244e-43 0 4.76441e-43 0 4.73639e-43 0 4.70836e-43] Recompiling with '-DmyInstanceNumberOrderIsNotSpatial' might help.

To reproduce

dcm2niix *.dcm Inside each series folders separately, data uploaded here

Expected behavior

3 separate nii's per INV1/INV2/UNI series of equal array dimensions.

Version

dcm2niiX version v1.0.20210317 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.4.0 x86-64 (64-bit Linux)

Troubleshooting

I tried to combine all images as mentioned in this closed issue but I'm not sure how to do this- does it require renaming the series to all the be same? https://github.com/rordenlab/dcm2niix/issues/502

neurolabusc commented 3 years ago

This is an issue with your dataset, not dcm2niix. You can see the issue by viewing the DICOMs with a dedicated DICOM viewing tool like Horos. For example, if you view sequential slices of the series Series_007_MP2RAGE_0.7_INV2 you will notice that most of the 224 slices are magnitude maps, but some are clearly phase maps (instance numbers 83, 130, 176, 190, 221).

You can also see this by renaming your DICOM images:

./dcm2niix -r y -f %s_%p_%4r.dcm -o ~/issue536/inv1 ~/MP2RAGE/Series_006_MP2RAGE_0.7_INV1

Note that some slices have ph at the end of their name (e.g. 7_MP2RAGE_0.7_0083_ph.dcm) while most do not (e.g. 7_MP2RAGE_0.7_0082.dcm).

You can view the DICOM header with a tool like Horos (click the Meta-Data) or export it as a text file with dcmdump or gdcmdump (e.g. dcmdump 7_MP2RAGE_0.7_0083_ph.dcm > ../83.txt. Viewing the DICOM headers clearly reveals that the image type (0008,0008) reports some as magnitude (M) and others as phase (P). 

(0008,0008) CS [ORIGINAL\PRIMARY\M\ND]   #  22, 4 ImageType

vs

(0008,0008) CS [ORIGINAL\PRIMARY\P\ND]   #  22, 4 ImageType

More concerning, the DICOM premable is missing (e.g. characters DICM not at offset 128), as is the Media Storage SOP Class UID (0002,0003). Since 0002,0003 is Type 1, your files are not valid DICOM images (I would refer to them as Siemens DICOM meta data). Therefore, these are not of archival quality and will cause unintended consequences with many tools.

My best guess is that someone exported DICOM meta-data rather than images. Each series contained 448 files (224 phase, 224 magnitude) with pairs of phase/magnitude images having identical instance numbers (0020,0013). This is legal: the DICOM standard does not require instance numbers to be unique. However, in my experience this is the leading cause for data loss for Siemens users, as many tools assume that the instance numbers are unique and will overwrite images when this is not the case. Many tools only look at instance numbers, but some tools will look wisely look at media Object Instance UID (0002,0003) (which is unique) to disambiguate naming conflicts. These tools are confounded by the fact that these files do not contain this (required, Type 1) tag.

Since only parts of the phase and magnitude images were provided to dcm2niix, it is impossible to reconstruct either scan.

You have two options:

  1. Export the data as valid DICOM images, with tools that do not overwrite when instance number is duplicated. dcm2niix will handle these datasets correctly.
  2. Export all the DICOM meta data files (e.g. 448 per series) directly off the scanner and convert them with dcm2niix. Even though the instance numbers conflict and the media UID is missing, dcm2niix will disambiguate the phase and magnitude images and convert them correctly.

As an aside, I see this is a research instrument running the developmental VE12. It is discouraging that this issue still persists in the upcoming software. For over a decade, I have been lobbying my Siemens Research Collaborations managers to ensure that instance numbers are unique. While duplicating instance numbers is technically valid, this has caused grief to many users. A quick web search identifies just a few cases where I have helped explain this catastrophic loss of data:

I urge all Siemens MR users (and particularly those at developmental sites that may have more influence) to lobby your Siemens Research Collaboration Managers to address this for V-series users (I believe this issue is not present for the X-series Vida and Sola). If we can fix this at the point where the data is acquired, we can prevent these errors.