questions
58 Subscribers 
questions > Help converting inconsistent slice distances
Showing 1-2 of 2 posts
Jan 27, 2021 01:01 PM | Paul Wright - King's College London
Help converting inconsistent slice distances
Hi
I'm having trouble converting certain images from the PPMI collection. I get the following from dcm2niix:
The output nifti looks complete, but the slice thickness is doubled from 1.2 mm to 2.4 mm in the nifti header, despite being listed correctly in the json sidecar. Obviously I could fix this by modifying the header, but it's a big dataset and I want to avoid too much manual adjustment. Is there a way to force dcm2niix to use the slice thickness it puts in the sidecar without using the recompiling option suggested?
I can send example data if needed, or if you already have PPMI, try image number I1350799. I've tried downloading this individual image a second time to see if this was just file corruption during download, but got the same result both times.
Thanks
Paul
I'm having trouble converting certain images from the PPMI collection. I get the following from dcm2niix:
Chris Rorden's dcm2niiX version
v1.0.20201102 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 x86-64 (64-bit
Linux)
Found 175 DICOM file(s)
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
Warning: Missing images? Expected 175 images, but instance number (0020,0013) ranges from 1 to 176
Convert 175 DICOM as test2/test2_MPRAGE_GRAPPA2_20191204081310_14 (240x256x175x1)
Unable to equalize slice distances: slice order not consistently ascending:
dx=[0 0 2.4 3.6 4.8 6 7.2 8.4 9.6 10.8 12 13.2 14.4 15.6 16.8 18 19.2 20.4 21.6 22.8 24 25.2 26.4 27.6 28.8 30 31.2 32.4 33.6 34.8 36 37.2 38.4 39.6 40.8 42 43.2 44.4 45.6 46.8 48 49.2 50.4 51.6 52.8 54 55.2 56.4 57.6 58.8 60 61.2 62.4 63.6 64.8 66 67.2 68.4 69.6 70.8 72 73.2 74.4 75.6 76.8 78 79.2 80.4 81.6 82.8 84 85.2 86.4 87.6 88.8 90 91.2 92.4 93.6 94.8 96 97.2 98.4 99.6 100.8 102 103.2 104.4 105.6 106.8 108 109.2 110.4 111.6 112.8 114 115.2 116.4 117.6 118.8 120 121.2 122.4 123.6 124.8 126 127.2 128.4 129.6 130.8 132 133.2 134.4 135.6 136.8 138 139.2 140.4 141.6 142.8 144 145.2 146.4 147.6 148.8 150 151.2 152.4 153.6 154.8 156 157.2 158.4 159.6 160.8 162 163.2 164.4 165.6 166.8 168 169.2 170.4 171.6 172.8 174 175.2 176.4 177.6 178.8 180 181.2 182.4 183.6 184.8 186 187.2 188.4 189.6 190.8 192 193.2 194.4 195.6 196.8 198 199.2 200.4 201.6 202.8 204 205.2 206.4 207.6 208.8 210 0 9.36258e-38 0 7.86128e-43 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 0 9.35468e-38 0 -nan 0 9.36107e-38 0 9.33049e-38 0 9.35809e-38 0 -nan -nan 9.36384e-38 0 9.3581e-38 0 0 0 9.36209e-38 0 9.36249e-38 0 -nan 0 9.36325e-38 0 9.36163e-38 0 5.47341e-16 4.55702e-41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
Recompiling with '-DmyInstanceNumberOrderIsNotSpatial' might help.
Found 175 DICOM file(s)
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
Warning: Missing images? Expected 175 images, but instance number (0020,0013) ranges from 1 to 176
Convert 175 DICOM as test2/test2_MPRAGE_GRAPPA2_20191204081310_14 (240x256x175x1)
Unable to equalize slice distances: slice order not consistently ascending:
dx=[0 0 2.4 3.6 4.8 6 7.2 8.4 9.6 10.8 12 13.2 14.4 15.6 16.8 18 19.2 20.4 21.6 22.8 24 25.2 26.4 27.6 28.8 30 31.2 32.4 33.6 34.8 36 37.2 38.4 39.6 40.8 42 43.2 44.4 45.6 46.8 48 49.2 50.4 51.6 52.8 54 55.2 56.4 57.6 58.8 60 61.2 62.4 63.6 64.8 66 67.2 68.4 69.6 70.8 72 73.2 74.4 75.6 76.8 78 79.2 80.4 81.6 82.8 84 85.2 86.4 87.6 88.8 90 91.2 92.4 93.6 94.8 96 97.2 98.4 99.6 100.8 102 103.2 104.4 105.6 106.8 108 109.2 110.4 111.6 112.8 114 115.2 116.4 117.6 118.8 120 121.2 122.4 123.6 124.8 126 127.2 128.4 129.6 130.8 132 133.2 134.4 135.6 136.8 138 139.2 140.4 141.6 142.8 144 145.2 146.4 147.6 148.8 150 151.2 152.4 153.6 154.8 156 157.2 158.4 159.6 160.8 162 163.2 164.4 165.6 166.8 168 169.2 170.4 171.6 172.8 174 175.2 176.4 177.6 178.8 180 181.2 182.4 183.6 184.8 186 187.2 188.4 189.6 190.8 192 193.2 194.4 195.6 196.8 198 199.2 200.4 201.6 202.8 204 205.2 206.4 207.6 208.8 210 0 9.36258e-38 0 7.86128e-43 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 0 9.35468e-38 0 -nan 0 9.36107e-38 0 9.33049e-38 0 9.35809e-38 0 -nan -nan 9.36384e-38 0 9.3581e-38 0 0 0 9.36209e-38 0 9.36249e-38 0 -nan 0 9.36325e-38 0 9.36163e-38 0 5.47341e-16 4.55702e-41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
Recompiling with '-DmyInstanceNumberOrderIsNotSpatial' might help.
The output nifti looks complete, but the slice thickness is doubled from 1.2 mm to 2.4 mm in the nifti header, despite being listed correctly in the json sidecar. Obviously I could fix this by modifying the header, but it's a big dataset and I want to avoid too much manual adjustment. Is there a way to force dcm2niix to use the slice thickness it puts in the sidecar without using the recompiling option suggested?
I can send example data if needed, or if you already have PPMI, try image number I1350799. I've tried downloading this individual image a second time to see if this was just file corruption during download, but got the same result both times.
Thanks
Paul
Jan 27, 2021 03:01 PM | Chris Rorden
RE: Help converting inconsistent slice distances
This is an limitation of your DICOMs and not my software. The
dataset is missing image instance 2, so the dataset has instances
1,3,4,...176. It is appropriate for dcm2niix to flag these partial
datasets as they require human intervention. In this case, you can
simply delete instance number 1, and then you will have virtually
the full dataset (3..176) of contiguous slices. A simple way to
sort DICOMs by instance number is to put the instance number into
the filename. You can use the dcm2niix renaming feature ("r -y")
with the instance number ("%r") in the filename to help. For
example:
./dcm2niix -r y -f %t/%s_%p/%4r.dcm ~/Downloads/PPMI
./dcm2niix -r y -f %t/%s_%p/%4r.dcm ~/Downloads/PPMI