Adding Correct Slice Timing Information Into JSON files

1

Hello! After converting my dicoms to nifti, I do not have slice timing information in my json files. I do know what the slice timing was/is-supposed to be. Siemen’s style, so with even slices (e.g. 32) it would be [2:2:32, 1:2:31]. However, I do not know how to add that to the JSON file in a format that fmriPrep likes/wants.

Would I just add to the JSON file
“SliceTiming”: “[2, 4, 6, 8…32, 1, 3, 5…31]”

Or is the format something else? I understand it uses afni’s 3dtshift but still do not understand the precise way I need to be recording the format of slice timing so fmriPrep is happy and does the slice timing adjustment properly.

Thanks!

2

fMRIPrep accepts datasets that are in BIDS format. According to BIDS:

Key name Requirement level Data type Description
SliceTiming RECOMMENDED, but REQUIRED for sparse sequences that do not have the DelayTime field set, and Arterial Spin Labeling with MRAcquisitionType set on 2D. array of numbers The time at which each slice was acquired within each volume (frame) of the acquisition. Slice timing is not slice order – rather, it is a list of times containing the time (in seconds) of each slice acquisition in relation to the beginning of volume acquisition. The list goes through the slices along the slice axis in the slice encoding dimension (see below). Note that to ensure the proper interpretation of the SliceTiming field, it is important to check if the OPTIONAL SliceEncodingDirection exists. In particular, if SliceEncodingDirection is negative, the entries in SliceTiming are defined in reverse order with respect to the slice axis, such that the final entry in the SliceTiming list is the time of acquisition of slice 0. Without this parameter slice time correction will not be possible.

So you’ll want your times to be something like [1, 3, 5...31, 0, 2, 4...30] / TR.

1 Like
3

Ah, thank you very much, that is extremely helpful. I wonder if it might be [1, 3, 5…31, 0, 2, 4…30] * (TR/numslices), so if TR was 2 and numslices was 32, then that would give something like [1/16, 3/16…31/16, 0, 2/16…30/16]

In which case, I just have to do the actual calculation of that and input the array from there.
So in the JSON file one might add:

“SliceTiming”: [0.0625, 0.1875, 0.3125…1.9375, 0, 0.125 … 1.875],

Obviously filling in those … with the other relevant values.

Thanks a ton!

1 Like
4

What kind of scanner is this coming from, and what software (and version) did you use to convert from dcm 2 nii? If you can get your slice timing information by upgrading to the most recent dcm2niix version, for example, that may be safer than the guesswork and human error involved in entering it manually.

5

This was also very helpful. I don’t know why, but the initial nifti and json files that had been converted before I started work simply did not have the slice time information. On a whim, and also thanks to this comment, I ended up going back to the raw dicoms and running a newer dcm2niix (through dcm2bids). This successfully grabbed the actual slice timing information!

The output seems to match the idea of [slice order] * (TR/numslices). So if this has to be done manually, then nailing down the slice order is the limiting step.

2 Likes
6

Good catch! Apologies for the too-quick response.

8

Hi @effigies I have a similar question. I’m working with an old dataset and don’t have dicoms or .json files with slice time info. I only have a scan protocol, which I will use to infer when each slice was acquired to give to fmriprep. Since slices were acquired in an interleaved and descending order (TR=2, 32 slices), does this order of slices look correct (where n is the nth slice)?

Interleaved and descending:
[32, 30, 28, 26, 24, 22, 20, 18, 16, 14, 12, 10, 8, 6, 4, 2, 31, 29, 27, 25, 23, 21, 19, 17, 15, 13, 11, 9, 7, 5, 3, 1]

Or, by time (TR=2, 32 slices):

Unique timing of each slice acquisition within a TR for reference:
[0, 125, 250, 375, 500, 625, 750, 875, 1000, 1125, 1250, 1375, 1500, 1625, 1750, 1875, 62.5, 187.5, 312.5, 437.5, 562.5, 687.5, 812.5, 937.5, 1062.5, 1187.5, 1312.5, 1437.5, 1562.5, 1687.5, 1812.5, 1937.5]

Interleaved and descending (input to fmri prep)
[1937.5, 1812.5, 1687.5, 1562.5, 1437.5, 1312.5, 1187.5, 1062.5, 937.5, 812.5, 687.5, 562.5, 437.5, 312.5, 187.5, 62.5, 1875, 1750, 1625, 1500, 1375, 1250, 1125, 1000, 875, 750, 625, 500, 375, 250, 125, 0]

Thanks to anyone who can help!!

9

Yes, that looks like a sensible interpretation of interleaved-descending to me.

Note that BIDS requires SliceTiming to be in seconds.

10

Great, thanks so much for your help!