Slice time correction

AFNI version info (afni -ver):


In the attached image I have mentioned the time duration (in the second column) when different slices of a volume are acquired. The fourth column shows the difference between the acquisition time of two consecutive slices. Sixth column shows the difference between the acquisition time of two slices (in the interleaved manner). Why in the fourth and sixth columns I am getting different values of the time difference? Can anybody please calculate TR from this data?

Thanks

Index(i) Ti T(i+1)-T(i) T(i+2)-T(i)
0 184.29 182.5 1.79 183.74 -0.55
1 182.5 183.74 -1.24 182.6375 0.14
2 183.74 182.6375 1.10 183.8775 0.14
3 182.6375 183.8775 -1.24 182.775 0.14
4 183.8775 182.775 1.10 184.015 0.14
5 182.775 184.015 -1.24 182.9125 0.14
6 184.015 182.9125 1.10 184.1525 0.14
7 182.9125 184.1525 -1.24 183.1875 0.28
8 184.1525 183.1875 0.97 184.4275 0.28
9 183.1875 184.4275 -1.24 183.325 0.14
10 184.4275 183.325 1.10 184.565 0.14
11 183.325 184.565 -1.24 183.4625 0.14
12 184.565 183.4625 1.10 184.7025 0.14
13 183.4625 184.7025 -1.24 183.6 0.14
14 184.7025 183.6 1.10 184.84 0.14
15 183.6 184.84 -1.24 183.05 -0.55
16 184.84 183.05 1.79 184.29 -0.55
17 183.05 184.29 -1.24 182.5 -0.55
18 184.29 182.5 1.79 183.74 -0.55
19 182.5 183.74 -1.24 182.6375 0.14
20 183.74 182.6375 1.10 183.8775 0.14
21 182.6375 183.8775 -1.24 182.775 0.14
22 183.8775 182.775 1.10 184.015 0.14
23 182.775 184.015 -1.24 182.9125 0.14
24 184.015 182.9125 1.10 184.1525 0.14
25 182.9125 184.1525 -1.24 183.1875 0.28
26 184.1525 183.1875 0.97 184.4275 0.28
27 183.1875 184.4275 -1.24 183.325 0.14
28 184.4275 183.325 1.10 184.565 0.14
29 183.325 184.565 -1.24 183.4625 0.14
30 184.565 183.4625 1.10 184.7025 0.14
31 183.4625 184.7025 -1.24 183.6 0.14
32 184.7025 183.6 1.10 184.84 0.14
33 183.6 184.84 -1.24 183.05 -0.55
34 184.84 183.05 1.79
35 183.05
type or paste code here

Hello,

Rather than an image of this table, would you be able to include a list of list times in plain text?

Thanks,

  • rick

Hi,
Edited the question. Now it shows a table of time in the text format.
Thanks

I loaded the numbers you supplied (thanks) into a spreadsheet (Google Drive) and sorted on the second column, T(i). The results from the first two columns are shown below:

i T(i) Difference
1 182.5 0
19 182.5 0.1375
3 182.6375 0
21 182.6375 0.1375
5 182.775 0
23 182.775 0.1375
7 182.9125 0
25 182.9125 0.1375
17 183.05 0
35 183.05 0.1375
9 183.1875 0
27 183.1875 0.1375
11 183.325 0
29 183.325 0.1375
13 183.4625 0
31 183.4625 0.1375
15 183.6 0
33 183.6 0.14
2 183.74 0
20 183.74 0.1375
4 183.8775 0
22 183.8775 0.1375
6 184.015 0
24 184.015 0.1375
8 184.1525 0
26 184.1525 0.1375
0 184.29 0
18 184.29 0.1375
10 184.4275 0
28 184.4275 0.1375
12 184.565 0
30 184.565 0.1375
14 184.7025 0
32 184.7025 0.1375
16 184.84 0
34 184.84
  • The table above shows that two slices are acquired at the same time.
  • This type of acquisition is called "multiband" -- in this case, the jargon is "multiband 2".
  • These pairs of slices are acquired 0.1375 s apart.
  • There are 18 pairs, so the time to acquire a single volume is 18*0.1375 = 2.475 s
  • Unless there is a time gap between the last slices of volume X and the first slices of volume X+1 (this type of gap not common), then the TR is 2.475 s

A detail to note:

  • The time difference T(2)-T(33) in my table is 1.4 s, not 1.375 (unlike all the other inter-slice pair time differences).
  • I suspect that this is due to a rounding error in the table given here.
  • If it is real, then you have to add 0.025 to the TR to get 2.5 seconds.
  • Resolving this point is important if this is a task-FMRI dataset, so that the task timings used in the data analysis are properly synchronized with the data.
  • It is quite possible that the TR was specified as 2.5 s, and so the MRI system stuck in that tiny hiccup of inter-slice pair timing to make it work out.

Another detail:

  • If you are going to process the data with AFNI, you'll want to load the slice timing offsets into the AFNI or NIFTI time series dataset. I won't explain how to do that here -- Rick Reynolds is probably more up-to-date on that than I am.
  • Me, I'm retired and have projects! A little carpentry, a little yardwork, and a little of plotting out my next novel.

Bob Cox = @AFNIman

1 Like

This looks almost like multiband level 2 and alt+z encoding.
If the times worked that way (and started at t=0), they could be evaluated with something like:

1d_tool.py -show_slice_timing_pattern -infile slice_times.txt

But there are 2 reasons this currently fails. One is the difference the illustrious Bob Cox mentioned, where .14 vs .1375 is too big of a difference (in the differences).

The other reason is that there are 2 times that do not fit the alt+z pattern. It actually looks like alt+z was intended, but 2 slice times are out of place, the 184.29 times at indexes 0 and 18. Those times appear to be in the "wrong" places. Whether that is an acquisition time problem or a slice time storage/tracking problem, I am not sure. But it is suspiciously close to MB 2, alt+z.

As it stands, it is merely shown as MB 1, irregular.

And as Bob mentioned, it is not clear what the TR should be. It looks like 2.477497, but that is a very strange time to use, and it is suspiciously close to 2.5.

  • rick

Thanks Bob for the detailed response. The TR given in the protocol file is 2.5s. I am checking other files for the discrepancy in time.

Thanks

Thanks rick.

I am checking other files for the discrepancy in slice duration. Thanks for your detailed answer.