Siemens: Negative Slice Times

[neurolabusc]

The Siemens CSA header can report negative values for the CSA parameter MosaicRefAcqTimes [0 -400 80 -320 160...]. We typically assume time zero refers to the start of the acquisition for the first slice in a volume, and therefore expect the minimum slice time to be zero. This situation occurs when Siemens Motion Correction (MoCo) is applied to some slice orders (e.g. interleaved).

Several teams have reported this problem

• neurostars
• heudiconv
• MRIcroGL
• stackoverflow

According to personal communication from Siemens The motion correction images are in anatomic order, while the non-moco data are in descending order, so the latest time is subtracted from each acquisition time resulting in the negative values. If you have an interleaved dataset we can more definitively validate this formula (aka sliceTime(i) - min(sliceTimes())).

Below is an example of two volumes from an anonymized ABCD dataset that exhibit this issue:

NegativeMosaicRefAcqTimes.zip

Development build v1.0.20190214 applies the formula suggested by Siemens.

[utooley]

I gave the development build a try, and get reasonable-looking slice times (though not the same as the other subjects scanned with the same sequence on a different scanner at the same, which of course is a bit puzzling). However, in addition to the output about Warning: Adjusting for negative MosaicRefAcqTimes (issue 271). I get a CSA slice timing warning CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 0..8.63999e+07, TR=800ms).

I know this isn't a CMRR sequence (as you had mentioned in a different thread about this issue), so I wanted to let you know--the relevant json file is attached, in case it's helpful.

__ABCD_fMRI_rest_20170404102628_8.txt

[neurolabusc]

I wonder if @mharms comments regarding the ABCD sequences for issues 245 and 272 apply, e.g. these are custom MGH SMS/MB sequences and the DICOMs are specially developed. Seems like @HaukeBartsch may be the world expert. In this case, dcm2niix is diligently reporting what is in the CSA header, but is also alerting you that the values are implausible. I do not think we can go any further without insight from the folks who generated these files.

[neurolabusc]

@utooley thanks for sending some sample ABCD images. The series where dcm2niix raises an alarm clearly have bogus volumes in the MosaicRefAcqTimes tag for the first volume, while the subsequent values look plausible. While the ABCD team use their own sequence, the problem with the first volume is similar to a historical CMRR issue. I do agree that the slice times acquired on the Prisma-Fit look a little bit different from the Prisma, both look plausible. Both have a TR of 800ms. I think on one MRI console the user chose to have the slices within the volume acquired as fast as possible (which left a temporal gap at the end of each volume) while on the other one the user chose to have the slices equally spaced in time (with tiny gaps after each set of slices).

Prisma-Fit 20170404 MosaicRefAcqTimes

First volume reports
sliceTimes 0	8.63996e+07	80	8.63997e+07	160	8.63998e+07	240	8.63998e+07	320	8.63999e+078.63996e+07	80	8.63997e+07	160	8.63998e+07	240	8.63998e+07	320	8.63999e+07	0	8.63996e+07	80	8.63997e+07	160	8.63998e+07	240	8.63998e+07	320	8.63999e+07	0	8.63996e+0780	8.63997e+07	160	8.63998e+07	240	8.63998e+07	320	8.63999e+07	0	8.63996e+07	80	8.63997e+07	160	8.63998e+07	240	8.63998e+07	320	8.63999e+07	0	8.63996e+07	80	8.63997e+07	160	8.63998e+07	240	8.63998e+07	320	8.63999e+07	
Subsequent volumes report
sliceTimes 400	0	480	80	560	160	640	240	720	320	400	0	480	80	560	160	640	240	720	320	400	0	480	80	560	160	640	240	720	320400	0	480	80	560	160	640	240	720	320	400	0	480	80	560	160640	240	720	320	400	0	480	80	560	160	640	240	720	320	

Prisma 20170516 MosaicRefAcqTimes

All volumes report 
sliceTimes 545	0	387.5	77.5	467.5	232.5	622.5	310	700	155	545	0	387.5	77.467.5	232.5	622.5	310	700	155	545	0	387.5	77.5	467.5	232.5	622.5	310	700	155545	0	387.5	77.5	467.5	232.5	622.5	310	700	155	545	0	387.5	77.5	467.5	232.5	622.5	310	700	155	545	0	387.5	77.5	467.5	232.5	622.5	310	700	155

[utooley]

@neurolabusc This is so insightful--thank you so much for your thorough investigation. This helps immensely in trying to figure out how to deal with those participants. I really appreciate it, will pass back along to other folks that I know have run into these sequences.

[satra]

@mgxd - i know our slice times were messed up in the voice project. would love to see an output from it in case the changes @neurolabusc implemented are related to our weird values.

[neurolabusc]

For completeness, this issue does not resolve the problem @satra had with some ABCD sequences. For these the slice times reported in the DICOM header is consistently wrong, and dcm2niix has no source for correct values. It correctly warns the user that the values do not make sense. One can observe the problem viewing the DICOM with a Hex Editor and looking for the tag MosaicRefAcqTimes. For these scans the TR=1090, but the slice times exceed this. I wonder if these were the single-band times for these slices. This looks like a custom sequence, rather than the Siemens product or CMRR sequence. Since the correct values are absent in this situation, the users will have to patch their JSON files with correct slice times (though with such a short TR, any slice time errors will be small).

MosaicRefAcqTimes=[0.00000000 2762.50000001 82.50000002 2847.50000000167.50000001 2930.00000002250.00000000 3015.00000001 335.00000002 3097.50000000 417.50000001 3182.50000002 502.50000000 3265.00000001 585.00000002 3350.00000001 670.00000001 3432.50000002 752.50000000 3517.50000002 837.50000002 3600.00000001 920.00000001 3685.00000000 1005.00000000 3767.50000002 1087.50000002 3852.50000001 1172.50000002 3935.00000000 1255.00000000 4020.00000002 1340.00000000 4102.50000001 1422.50000002 4187.50000000 1507.50000001 4270.00000002 1590.00000000 4355.00000001 1675.00000002 4437.50000000 1757.50000001 4522.50000002 1842.50000000 4605.00000001 1925.00000002 4690.00000000 2010.00000001 4772.50000002 2092.50000000 4857.50000001 2177.50000002 4940.00000000 2260.00000001 5025.00000002 2345.00000000 5107.50000001 2427.50000002 5192.50000000 2512.50000001 5275.00000002 2595.00000000 5360.00000002 2680.00000002]

"ImageComments": "SMS_MGH_V2.1;_MB=5;_FOVshift=3;_K_PE=3;_K_RO=3;_CCR=1;_LeakBlockOn;",
"PulseSequenceDetails": "%CustomerSeq%_ep2d_bold_SliceAcc_770A",

[neurolabusc]

Just a comment that the current stable release (v1.0.20210317) will often generate false alarms that refer to this issue: Adjusting for negative MosaicRefAcqTimes (issue 271). This is resolved in the development branch and will be fixed in the Fall 2021 stable release. This warning has caused warnings (here, here, and here).

In general, users can ignore this warning. Most of the times, this is a false alarm. On the other hand, if the data really is using Siemens Motion Correction, the slice times will be corrected using the formula suggested by Siemens (mentioned above).