Download Mricrogl

[Imogen Petrusky]

Ihave 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.

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.

3a8082e126