I don’t know about the first question, but Siemens reports slice timing accurate to only 2.5ms. That precision ultimately derived from limitations in its physiology recording system regardless of whether you use any physiology recordings. While the recording of the time in the DICOM header could be off by 2.5 ms, we (Vinai Roopchansingh) were able to check on a high temporal precision scan protocol with an oscilloscope to verify the actual timing was much more exact, so there was little to worry about. In that case, computing the alt+Z acquisition times would yield the correct times, but trying to extract the times from the headers would be slightly off.
@cfarr I would ask your center’s Siemens Research Collaboration Manager to answer the first question for you. They have a lot of internal information on your scanner. I recall for Philips using dynamic motion correction did add about 17ms at the end of each volume.
Thanks for your replies - they’re much appreciated! @dglen - what do you mean by ‘computing the alt+Z acquisition times’? Are you referring to some AFNI protocol?
Sorry to be confusing; that was just an example. With whatever slice timing order you have, you can then compute the slice times from that - alt+Z, alt-Z, seq+Z, seq-Z, multi-band,… Here’s an example that is from AFNI’s 3dTshift help.
For example if nz = 5 and TR = 1000, then the inter-slice
time is taken to be dt = TR/nz = 200. In this case, the
slices are offset in time by the following amounts:
S L I C E N U M B E R
tpattern 0 1 2 3 4 Comment
--------- --- --- --- --- --- -------------------------------
altplus 0 600 200 800 400 Alternating in the +z direction
alt+z2 400 0 600 200 800 Alternating, but starting at #1
altminus 400 800 200 600 0 Alternating in the -z direction
alt-z2 800 200 600 0 400 Alternating, starting at #nz-2
seqplus 0 200 400 600 800 Sequential in the +z direction
seqminus 800 600 400 200 0 Sequential in the -z direction
Here are my notes on Siemens slice timing. I also like this page that provides SPM/Matlab code for computing slice timing patterns. You might want to look at my Python script but that was designed for Philips and GE, and does not currently deal with the fact that Siemens interleaved starts with the first or second slice depending on number of slices in the volume.
Thanks for the useful information, @dglen and @neurolabusc. If my understanding is correct, then, using dcm2niix should circumvent the problem of reduced precision in dicom header encoding of slice timing?
dcm2niix is limited by the precision provided by the manufacturer in the DICOMs. Typically, there are rounding errors for many parameters including slice timing, b-values, etc. However, the precision is typically very high for the required application. Remember for slice timing, you are trying to adjust for the low frequency of the human hemodynamic response function - which is something like 1/24th Hz. Faster physiological responses like breathing and heart beat are still relatively low frequencies. Ultimately, the sampling rate (TR) sets limits on the resampling, and one should consider the Nyquist for those.