Slice timing: General Electrics versus Siemens

Hi all,

I am trying to infer the slice timing from a GE dataset in BIDS format. When looking at the dcm_qa and dcm_qa_ge DICOM to NIfTI validator scripts by @neurolabusc, I noticed that Siemens derived slice timings often have a slightly irregular first and last slice-timing interval, while GE derived slice timings do not.

For example:

GE derived (each interval is 0.11):

"SliceTiming": [
		0,
		0.111111,
		0.222222,
		0.333333,
		0.444444,
		0.555556,
		0.666667,
		0.777778,
		0.888889,
        (...)

Source: dcm_qa_ge/Ref/Ax_fMRI_HB8_72sl_seq_asc_3.json at master · neurolabusc/dcm_qa_ge · GitHub

Siemens derived (first interval is 0.1375, subsequent intervals are 0.1400) :

"SliceTiming": [
		0,
		0.1375,
		0.2775,
		0.4175,
		0.5575,
		0.6975,
        (...)
]

Source: dcm_qa/Ref/fMRI_MB_asc_25.json at master · neurolabusc/dcm_qa · GitHub

Does anyone now why the first and last slice timing intervals are irregular for scans from a Siemens scanner and not for scans from a GE scanner in this case? And if so, if this observation is indeed a general scanner related difference?

Thank you!

Best,

Thomas

Thomas dcm2niix assumes that the DICOM images are truthful. Note that for the Siemens image you refer to, dcm2niix is faithfully converting the MosaicRefAcqTimes tag from the Siemens CSA header to seconds. You can see this by viewing the DICOM with a hex editor:

Screenshot 2024-07-17 at 10.50.18 AM

DICOM files often exhibit small errors due to rounding errors, particularly for variables stored as text. However, sequences also have small variations added in to pad adjustments. A nice example of this is the Philips slice timing gap due to Prospective Motion Correction. Multi-band sequences add an extra layer of complication. The variability you have spotted is negligible with regards to the sluggish hemodynamic response we are trying to compensate for with slice timing correction, so I think you have permission to ignore. However, feel free to follow this up with the Siemens Research Collaboration Manager associated with your center (though they may note that the example you provide was an early CMRR research sequence, so you should look to see if you see similar variability in Siemens product sequences).

Thank you a lot for the extensive explanation @neurolabusc! And I will look into the newer sequences.

From what I understand, the slice timing in the Siemens header is based on a temporal resolution of 2.5 ms. I believe this is related to the sampling frequency of their physiological recordings, but has propagated into the timing. As Chris points out, this is rarely a problem for FMRI, but it sometimes is (which is why I know about it). At NIH, Vinai Roopchansingh confirmed with an oscilloscope that requested alt+Z slice timing actually results in the correct timing despite the header’s slight imperfections.

Interesting! Just out of curiosity, do you have an example where this is actually a problem?

No, it wasn’t really a big problem but approaching something important. In any case, the real slice timing was correct, just not the one in the DICOM headers.

1 Like