SliceTiming in json correct?

Software Support
, ,
1

Dear experts,

I want to confirm that the SliceTiming in my json files is correct. The PhaseEncodingDirection definitely is, the RepititionTime as well. Number of slices is 40. I am quite new to processing fMRI data, and the SliceTiming was given to me by someone else. I assume the timings are correct, I am just wondering if it is correct to end and not start with 0?

This is the relevant information from the json files:

“PhaseEncodingDirection”: “j-”
“RepetitionTime”: 2.2,
“SliceTiming”: [2.145, 2.09, 2.035, 1.98, 1.925, 1.87, 1.815, 1.76, 1.705, 1.65, 1.595, 1.54, 1.485, 1.43, 1.375, 1.32, 1.265, 1.21, 1.155, 1.1, 1.045, 0.99, 0.935, 0.88, 0.825, 0.77, 0.715, 0.66, 0.605, 0.55, 0.495, 0.44, 0.385, 0.33, 0.275, 0.22, 0.165, 0.11, 0.055, 0.0]
}

Thank you very much for your help.

2

Yes, that is valid. In general, if sorted(SliceTiming) == [0..nslices-1] * TA / nslices, where TA is acquisition time (typically the same as repetition time), it’s a reasonable SliceTiming.

What you have here is a descending slice ordering, corresponding to nipy.algorithms.slicetiming.timefuncs.st_43210().

1 Like
3

Ok, that makes sense. Thanks a lot!

This one might be a bit more tricky:
In another scan, which is multi echo (echoes) I am questioning the SliceTiming and SliceOrder in the json files. I am not confident about this at all, as entering these numbers was rather rushed, by someone who tends to make mistakes, and I didn’t completely follow through.
The NumberOfSlices is correct, as is the MultibandChannels.

This is what is in the json file:

“NumberOfSlices”: 38,
“MultibandChannels”: 2,
“SliceOrder”: [
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 1, 3, 5, 7, 9, 11, 13, 15, 17],
[19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 20, 22, 24, 26, 28, 30, 32, 34, 36]
],
“SliceTiming”: [
0.0, 1.15789474, 0.11578947, 1.27368421, 0.23157895, 1.38947368,
0.34736842, 1.50526316, 0.46315789, 1.62105263, 0.57894737, 1.73684211,
0.69473684, 1.85263158, 0.81052632, 1.96842105, 0.92631579, 2.08421053,
1.04210526, 0.0, 1.15789474, 0.11578947, 1.27368421, 0.23157895,
1.38947368, 0.34736842, 1.50526316, 0.46315789, 1.62105263, 0.57894737,
1.73684211, 0.69473684, 1.85263158, 0.81052632, 1.96842105, 0.92631579,
2.08421053, 1.04210526
]

But I think according to the content of the PAR of the Phillips Achieva Scanner, the slice acquisition order should be different.

Following the structure of the PAR file, if I follow the same pattern which in the single echo scan PAR file I find goes from 40 down to 1, I find this pattern in the ME data:
1 3 5 7 9 11 13 15 17 19 2 4 6 8 10 12 14 16 18 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Yet, given that this is multi band, acquired interleaved, I really don’t know how this should be specified in terms of SliceTiming and SliceOrder.

I’ll provide an excerpt from the PAR file here as a txt file.

Thank you very much in advance for your help on this one as well.

excerpt PAR multi echo.txt (78.1 KB)

4

The slice timing does not appear to be explicitly recorded in that file. I would probably consult your Philips rep to figure out your slice timing.

5

Ok, I sent an email to our research support and asked if they can help me reach out to the Philips support. I’ll send an update here when I know more. Thank you!

6

Actually, this seems okay to me. Running these times through AFNI’s
1d_tool.py -show_slice_timing_pattern
it shows: nbands : 2, tpattern : alt+z

And that seems to match the other fields: 2 multiband channels, plus a slice order of evens then odds for 2 halves of the slices (well, even then odds along with odds then evens, since 38 is not a multiple of 4).

-rick

7

Oh sorry, the values are consistent in the json file, but not spelled out in that PAR file (though the file name says “excerpt”, and so might miss the pertinent details?). I’ll be quiet again…
-rick