GE Number of slice error

[xfgavin]

So basically, I will just copy what I posted before.

I am not sure how dcm2niix determines number of slices, but in my case there is a private tag (0021,104f) addressing this.

Here is the anonymized dataset

Hi there,

I found dcm2niix has some problem determining number of slices per volume for some GE BOLD fieldmap data (DV26). In my case, the data is a 128 x 128 x 60 x 8 matrix however, dcm2niix thinks it is a 128 x 128 x 240 x 2 matrix.

Here is the dcm2niix output
../dcm2niix .
Compression will be faster with 'pigz' installed
Chris Rorden's dcm2niiX version v1.0.20190410 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 (64-bit Linux)
Found 480 DICOM file(s)
slices stacked despite varying acquisition numbers (if this is not desired recompile with 'mySegmentByAcq')
Convert 480 DICOM as ./anonymous_1.2.840.113619.6.408.182238963867883925330132808668133220387_1.2.840.113619.2.408.4738430.14026340.32333.1556736885.550_20190620134748_16_t29477 (128x128x240x2)
Conversion required 1.448439 seconds (0.552041 for core code).

[neurolabusc]

Thanks for sharing. If you build from the development branch you will find that it now gives precedence to the private tag 0021,104F if it disagrees with the public tag 0020,1002. It will also generate a warning if you convert one of these images in verbose mode:

Check number of slices, discrepancy between tags (0020,1002; 0021,104F; 0054,0081) (60 vs 240)

However, this modification reveals a fatal error in your data: some images are saved with the row order reversed relative to others (making some images appear flipped in the anterior-posterior direction). This is not a limitation of dcm2niix, but an inherent limitation in your DICOM images (you can see this with any DICOM tool). I suggest you contact your GE research collaboration manager to resolve this.

[xfgavin]

Got it. Thanks for the helps!

[dagra]

Hi,

i have a case which is a 3D T1 from GE/SIGNA_Architect with dimensions (252, 512, 512). In the latest release it is incorrectly converted to an image with shape (512, 512, 126, 2), whereas previously it was converted correctly. As far as i can tell, this is caused by the relevant commit of this issue because the relevant tags are the following:

(0020,1002) IS [252]                                    #   4, 1 ImagesInAcquisition
(0021,104f) SS 126                                      #   2, 1 LocationsInAcquisition

Does this mean that these dicom tags of my case are faulty? Unfortunately i don't have many cases from GE to compare and determine which is correct.

[neurolabusc]

Can you please test with the latest developmental build. On Unix systems you can get this from

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

Of Windows, you should be able to get the latest developmental build compiled by AppVeyor. The latest developmental commit should report as version v1.0.20191031.

If the problem persists, I think I would need to look at a sample dataset to understand what is going on. I wonder if this is a scan that was interpolated in the slice direction.

[dagra]

I tested with the latest developmental build and the problem persists.

Chris Rorden's dcm2niiX version v1.0.20191031  (JP2:OpenJPEG) (JP-LS:CharLS) GCC7.4.0 (64-bit Linux)
Found 252 DICOM file(s)
Convert 252 DICOM as ./image-000229.dcm (512x512x126x2)

I sent you via email the dataset. If you prefer another way to send you the data, please let me know.

Thanks!

[neurolabusc]

Thanks for the sample dataset. If you run dcm2niix in verbose mode it notes Check number of slices, discrepancy between tags (0020,1002; 0021,104F; 0054,0081) (126 vs 252). Seeing your new data, I think this discrepancy can come from two sources: for 4D EPI volumes these report dim[3] and dim[3]*dim[4], while for non-EPI scans these report number of slices acquired versus number of slices interpolated. My guess is that your data was acquired with 126 slices, but reconstructed to 252. If possible, I would always save DICOM data without interpolation. This creates smaller files and allows better post-processing (mrdegibbs).

Regardless, I do not know of anyway to resolve this discrepancy when reading each 2D slice. My latest commit resolves this by examining the number of repeated slice positions when saving the 3D/4D files. This should comprehensively address this issue.

Thanks for the example.

[dagra]

No problem.

I can confirm it's solved in this example.

Thanks!