Hello,

I'm encountering issues while trying to convert DICOM files to NII files using dcm2niix(version v1.0.20230411  Clang14.0.0 ARM (64-bit MacOS)), due to some warning messages. I'm processing data from two different centers, and they are showing different warning messages.

For the first center, which used a MAGNETOM Trio scanner, I'm getting the following warnings for image types of EPI, REST and DTI.

Warning: Weird CSA 'ProtocolSliceNumber' (System/Miscellaneous/ImageNumbering reversed): VALIDATE SLICETIMING AND BVECS

Warning: Assuming mosaics saved in reverse order due to 'sSliceArray.ucImageNumb'

For the second center, which used a MAGNETOM Vida scanner, I'm getting the following warning for EPI and DTI data:

EPI and DTI appear to have

CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 8350..9085, TR=835 ms) / CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 44800..47837.5, TR=3200 ms

Even though these warnings are appearing, the NII files seem to open correctly. I will be using EPI and DTI images, so is it safe to proceed with the analysis as is? If there might be an issue, what kind of processing can be done? I've attached the JSON files as well.

Thanks in advance.

additional json files.

additional json files! Thanks.

Hello,

 Both of these are warnings not edge cases, where you as the user must ensure everything is correct. These reflect datasets where I have had little exposure and where it is possible that the solution is not robust

The weird protocol slice number reflects a sequence that was run with with H>>F. Presumably, the person who set up the sequence assumed that this would create descending acquisitions, but this is not the case. As Siemens notes: "Do not use the mode H>>F because this complicates the numbering and you will have to sort images manually in most fMRI post-processing tools. The excitation of the slices in this case also starts caudally with the highest image numbers counting backwards!" I would strongly suggest users follow Siemens recommendations, and I obviously have few exemplars where users explicitly disregard the manufacturer expectations.

https://marketing.webassets.siemens-healthineers.com/1800000001646277/f90d901c54b7/Flash60_HIDI_Slicetiming_Graessner_final2_KORR.pdf

Some Siemens Vida's had early versions of Siemens XA, which did not provide accurate slice timing in all situations. This is fixed by upgrading the scanner (I believe XA20 and later are robust). Regardless, when you see this warning you will want to inspect the slice timing values to make sure they are correct.

It's not clear which sequence you're referring to, but I did get an image with F >> H. I'm attaching the relevant protocol. If this still happens, can I just use the data for analysis? 

If not, I was wondering if there is a way to fix it in post-processing. 
Thanks for your quick response.

The foot head issue seems to reflect the setting of the Trio data. I have very little experience with these images. For existing images, you should make sure the spatial orientation, slice timing and gradient vector direction are correct. For future acquisitions, make sure that the default image numbering is used. If you have any questions you should seek the help of the Siemens Research Collaboration Manager associated with the site where the data was acquired. I have done my best to robustly handle data from a wide array of devices, but my software will generate warnings in situations where I have do not have enough experience to provide confident conversions.