Problems with b2500 and b700 dwi data

[stremblay18]

Describe the bug

I have issues with DWI data that we acquired recently (had no issue with other acquisitions from the same imaging protocol). For some participants, conversion of the b2500 and sometimes b700 data gives me warnings and then I cannot view the output nifti image (I tried different softwares: MRIcroGL, mrview). Mrinfo gives me voxel size = 2 x 2 x 0 (I would expect 2 x 2 x 2).

There is likely a problem with the acquisition, but we cannot trace back the issue. Our MR tech did not notice anything wrong during these scans, and no dicom header seem to be missing. I also would like to figure out if I can recover this data somehow (for instance, I could remove some problematic volumes if the issue is constrained to these volumes.

To reproduce

Steps to reproduce the behavior:

1. dcm2niix -b y -z y -i n -f '%f%p%t%s%e_%a' -o ../../nifti/Test/ 1.3.12.2.1107.5.2.19.45281.30000023110209491189500028039/
2. I get these warning messages:

Warning: Seconds between volumes varies Warning: Unable to determine slice direction: please check whether slices are flipped (derived image) Warning: Siemens XA exported as classic not enhanced DICOM (issue 236) Convert 2418 DICOM as ../../nifti/Test/1.3.12.2.1107.5.2.19.45281.30000023110209491189500023170_ep2d_diff_b700_PA_20231102082211_1029_1_Head_32 (128x128x78x31) Conversion required 6.161292 seconds (4.850819 for core code).

and several lines of this type of warning (several identical ones, for a few different series):

Warning: Series 29 includes partial volume (issue 742): 1 slices acquired but ICE dims (0021,118e) specifies 78 (This warning doesn't seem to be the cause of the issue and appears when converting non-problematic data)

Expected behavior

For other participants, the conversion completes without problem, output images (in nifit) have voxel dimensions of 2 x 2 x 2, can be viewed without issue and have the expected appearance.

Version

I'm using this version:

Chris Rorden's dcm2niiX version v1.0.20240202 (JP2:OpenJPEG) (JP-LS:CharLS) Clang11.0.0 x86-64 (64-bit MacOS)

I also tried earlier versions (on Mac and on Linux) and got different errors and outputs:

Errors with version 2018:

Chris Rorden's dcm2niiX version v1.0.20181125 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 (64-bit Linux) Found 5070 DICOM file(s) slices stacked despite varying acquisition numbers (if this is not desired recompile with 'mySegmentByAcq') 390 images have identical time, series, acquisition and instance values. DUPLICATES REMOVED. Warning: CSA slice timing appears corrupted (range 0..0, TR=6000ms) Convert 4680 DICOM as /home/remoteuser/treste/Documents/temp_nifti_CIRM/1.3.12.2.1107.5.2.19.45281.30000023110209491189500012647_ep2d_diff_b2500_PA_20231102082211_26_1_Head_32 (128x128x78x60) compress: "/usr/bin/pigz" -n -f -6 "/home/remoteuser/treste/Documents/temp_nifti_CIRM/1.3.12.2.1107.5.2.19.45281.30000023110209491189500012647_ep2d_diff_b2500_PA_20231102082211_26_1_Head_32.nii" Conversion required 26.263383 seconds (7.426647 for core code).

Errors with 2022 version:

Chris Rorden's dcm2niiX version v1.0.20220720 (JP2:OpenJPEG) Clang15.0.0 ARM (64-bit MacOS) Found 5070 DICOM file(s) Warning: Seconds between volumes varies Warning: Siemens MoCo? Bogus slice timing (range -1..94872.5, TR=6000 seconds) Warning: Unable to determine slice direction: please check whether slices are flipped Warning: Siemens XA exported as classic not enhanced DICOM (issue 236)

I would appreciate any help.

[neurolabusc]

@stremblay18 can you share a sample dataset with my institutional email?

I think the core problem is that the data was exported from a modern Siemens XA MR in classic instead of enhanced DICOM format. The solution is to export the data from the MRI console as enhanced format.

Please see this public service annoncement - it is really important that XA data is never exported as mosaics, and the classic DICOMs are impoverished. The situation is catastrophic with XA10 and XA11, and somewhat better with XA20 and later.

The Siemens Research Collaboration Manager associated with your center can provide advice on using the new XA architecture.

[stremblay18]

Thank you very much for the quick response. I sent a sample dataset (one with and onw without problem) to your email. Let me know if you haven't received it.

I'm trying to figure out, as a priority, if the data can be recovered somehow (perhaps excluding problematic volumes).

Best,

[neurolabusc]

I have received your image. Not sure what is wrong with this, but both dicm2nii and dcm2niix are unhappy with it. In the short term, I suggest either exporting data to enhanced DICOM or using the MRtrix conversion, which seems to handle your images. I will return to this issue when I have some down time.

[stremblay18]

Thank you so much, I just tried with mrtrix and it indeed does work! I advised the MR tech that the issue may be due to the export.

[neurolabusc]

@stremblay18 thanks for sharing the data. This is challenging, as the dataset has two errors though both may be consequences of the same root problem. One problem is that the IntanceNumbers (0020,0013) are not unique within a series. While DICOM allows this, in practice all other manufacturers ensure instance numbers are unique and many tools assume this. While I have seen this before for Siemens fieldmaps including this validation dataset, this is the first time I have seen this behavior in a diffusion series. I have added a kludge to dcm2niix that substitutes the Siemens Private Tag frameNumberInSeries (0021,118a) for instance number if the former exists.

A larger problem is your Series Number 26, where some images are missing and others have been removed. Consider these binary identical duplicates:

1.3.12.2.1107.5.2.19.45281.30000023110209491189500013169.dcm
1.3.12.2.1107.5.2.19.45281.30000023110209491189500013169(1).dcm
1.3.12.2.1107.5.2.19.45281.30000023110209491189500013169(2).dcm

I note that this data was touched by a PACS, and I wonder if the duplicated instance numbers confounded your tools:

(0002,0013) SH [AQNET44B-470]                           #  12, 1 ImplementationVersionName