Hi All,
I recently converted a sample of my data from #dicom to #nifti using #mricrogl, and received several (similar) warnings (see attached screenshot for one participant) on different subjects. In summary, the warnings revolve around:
- Slice Timing
- Weird CSA ‘Protocol Slice Number’
- Mirroring of 2D images
I have read both the mricrogl and dcm2nii MediaWiki and was only able to find information about the software not correcting for slice timing. In short, I am wondering if these warnings could create issues later (i.e. as I move through pre-processing and analysis)? As an FYI, once formatted, the data did pass the #bids validator.
I would suggest checking the “Ignore Derived and 2D Images” option - this invokes the -i y argument that will skip files you do not need (localizers and derived FA/MD/Trace images you can recreate better after processing).
The Weird CSA ‘Protocol Slice Number suggests that the user switched the Image Numbering on the console. Presumably, they thought they were switching the acquisition (e.g. from ascending to descending), but this option only changes the order images are stored in the mosaic, not the order they are acquired. This is such an unusual option, handling of these images is not well validated. I would suggest you acquire a simple validation dataset to ensure that the slice ordering and slice timing are what you expect and match the dcm2niix output.
If you enable Motion Correction (MoCo) on a Siemens console, it can report negative slice times. In general, I would suggest acquiring data without acquisition-based motion correction. You will want to correct for this off-line and use any motion parameters as regressors for your analysis.
My biggest concern is the Interslice distance varies error for your multi-echo PD/T2 sequence. Be aware that Siemens will not use unique instance numbers for multi-echo sequences. Rather, it will re-use the same instance number for different echoes of the same sequence. I suspect your PACS archival system assumed unique instance numbers and overwrote some slices of echo 1 with images from echo 2 and vice versa. You will want to check the provenance of your images and work out which stage caused the over-writing. You may also want to lobby your Siemens Research Collaboration Manager to use unique instance numbers, but the DICOM standard does not require this. So while these images cause data loss with many tools, they are in fact valid images.
I suspect that dcm2niix handled these images as well as it could given the input. However, there are some very atypical options here. Given the resources devoted to acquiring and analyzing MRI data, I would suggest reviewing the sequences carefully and ensuring they do what you want. Specifically, I would reach out to your Siemens Research Collaboration Manager and ask them to review your sequences. In my experience, they can give you terrific advice and have great insight into how to optimize your sequences.
