Summary of what happened:
Dear experts,
I have a question regarding slice timing correction when using the docker container of fmriprep 23.2.1. The TR of my fMRI data is 3 seconds, however, there is a 1-second delay in TR. The relevant information from the fMRI JSON file is as follows:
“DelayTime”: 1,
“RepetitionTime”: 3,
“SliceTiming”: [1, 0, 1.05469, 0.04688, 1.10938, 0.10156, 1.15625, 0.15625, 1.21094, 0.21094, 1.26562, 0.26562, 1.32031, 0.3125, 1.375, 0.36719, 1.42188, 0.42188, 1.47656, 0.46875, 1.53125, 0.52344, 1.58594, 0.57812, 1.63281, 0.63281, 1.6875, 0.6875, 1.74219, 0.73438, 1.79688, 0.78906, 1.84375, 0.84375, 1.89844, 0.89844, 1.95312, 0.95312]
I am wondering if the delay in TR was taken take of when performing the slice timing correction. Here is the STC commands.txt I found in the working directory:
Command used (and if a helper script was used, a link to the helper script or the command generated):
3dTshift -ignore 0 -prefix sub-150701_task-rest_run-01_bold_tshift.nii.gz -tpattern @slice_timing.1D -TR 3s -tzero 0.977 /scratch/fmriprep_23_2_wf/sub_150701_wf/bold_task_rest_run_01_wf/bold_native_wf/bold_stc_wf/slice_timing_correction/sub-150701_task-rest_run-01_bold.nii.gz
Given the 1-second delay in TR, the “effective” TR becomes 2 seconds. Does the 3dTshift command accommodate this situation? Any insights on this concern would be greatly appreciated.
Best regards,
Mary