3dtshift tpattern flag

AFNI Message Board
1

Hello,
I am running 3dTshift and trying to figure out which option to use for the -tpattern flag. The SliceTiming field in my bids json file looks like this:
"SliceTiming": [0, 0.06, 0.1175, 0.1775, 0.2375, 0.295, 0.355, 0.415, 0.4725, 0.5325, 0.5925, 0.6525, 0.71, 0.77, 0.83, 0.8875, 0.9475, 1.0075, 1.065, 1.125, 1.185, 1.2425, 1.3025, 1.3625, 1.42, 1.48, 1.54, 1.6, 1.6575, 1.7175, 1.7775, 1.835, 1.895, 1.955, 2.0125, 2.0725, 2.1325, 2.19, 2.25, 2.31, 2.3675, 2.4275, 2.4875, 2.5475, 2.605, 2.665, 2.725, 2.7825, 2.8425, 2.9025, 2.96]. The TR is 1.5s, and my understanding is that this SliceTiming field is not supposed to exceed the TR. I can't input the SliceTiming from here as my tpattern option because it ends up failing. How do I know which option to use?

2

Hi-

It seems odd, and mismatched, to have an explicit slice timing that goes to ~3 s, while the purported TR is only 1.5s. I would double check what is happening there. Is the number of slices consistent with the explicit SliceTiming list length? It is difficult to see how those two pieces of information are consistent, and so it seems necessary to sort out what is correct first.

In a case where you had the slice timing pattern, you could add the timing directly to a DSET:

abids_tool.py                             \
    -add_slice_times                      \
    -input  DSET

... assuming that DSET has a JSON sidecard with that SliceTiming.

--pt

3

Yes, the number of slices is consistent with the SliceTiming list. The scanner sequence specifies 51 slices and this list consists of 51 times.

This is an older dataset from a few years ago before I had joined my lab. Our newly collected data seems to have the correct SliceTiming list. With the new data, I am able to just take the SliceTiming list and apply it to the -tpattern flag. However, I am not exactly sure what to do with this old data. My only other thought is that maybe it has to do with the pattern that it was collected? Our new data is being collected as interleaved, ascending.

4

It is pretty odd that the older data doesn't have interleaved acquisition. Do you/someone else in the lab have the DICOMs around of that original data? This discrepancy and the oddness of the timing values suggests that a deeper layer of inquiry may be needed, to earlier forms of the dataset.

--pt

5

Yes we have dicoms of the data. Is there something I should look for specifically in these dicoms?

6

I am looking at the raw dicoms, but not entirely sure what to look for. I tried using dicom_hinfo to pull tags 0020,0013 (InstanceNumber) and 0020,1041 (SliceLocation), but wasn't able to decipher much.

From the SliceTiming list in the json file, is it safe to assume it was acquired sequentially ascending?