slice-timing correction does not work with a multiband protocol

AFNI Message Board
1

Hello AFNI experts,

3dTshift seems to not change anything in my data.

DETAILS:
I have data that was scanned using a multiband protocol (acceleration factor of 2), in a Siemens Magnetom Prisma 3T. My data consists of 64 slices, acquisition was interleaved.
I want to use 3dTshift on this data. As I understand, AFNI can automatically read the order of acquisition from the header, which suits a multiband acquisition.
I compared the data before 3dTshift and after, using 3dinfo -slice_timing, and both outputs are just a list of 64 zeros, indicating nothing has happened. When not running my script in a loop, I also notice a warning that “dataset is already aligned in time”.
The metadata in the DICOM does show that acquisition was multiband, two slices acquired every 65.5 ms (2 and 34, then 4 and 36, etc.). I should expect the output of 3dinfo -slice_timing to mirror the times of the acquisition, no?

So I’m confused: Is it the scanner that alignes it automatically (if so - how do I find it in the protocol)? Does it have to do with the fact that it is a MB protocol? Or does AFNI not know how to access the information of the order of acquisition? Or is this information lost in the transformation from DICOM to nifti/AFNI?

Thank you!

2

It sounds like the information was lost to me - how did you convert the data? with dcm2niix, the files do not have the AFNI headers (if I’m using that term correctly) that 3dTshift would read. I use the .json files that dcm2niix produces, and create a timing file. This can then be passed to 3dTshift (or afni_proc) using something like:


-tpattern @${codedir}/sub-01/sess-v4/slicetimes.txt     \

where the slice times is just a text file with a single value (in seconds) on each row, with the number of rows = number of slices.

I copy and paste right out of the .json file produced by dcm2niix, remove the spaces and commas and call it a day. Only needs to be done once.

3

Thank you, I extracted the slice times from the dicom header with matlab, and saved it as a text file (one row, numbers in seconds, no spaces or commas). I tried to run it as you suggested, with explicitly calling this text file:


3dTshift -tpattern @slice_times.txt -prefix S03_Run1.data.tshift S03_Run1.data+orig

But when I test the output using


3dinfo -slice_timing S03_Run1.data.tshift+orig

I still get just a list of zeros. I.e. no slice timing correction.
Any idea what might have went wrong?

4

UPDATE:
I now tried to specify the tpattern first via 3dTshift:


3dTcat -tpattern @/media/galit/'Seagate Expansion Drive'/fMRI_GALIT/slice_times.1D -prefix S03_Run1.data.t S03_Run1.data+orig

Now when I ask for slice timing with 3dinfo, I get the timing vector and not just a list of zeros.

I apply 3sTshift on the output of 3dTcat:


3dTshift -tpattern @/media/galit/'Seagate Expansion Drive'/fMRI_GALIT/slice_times.1D -prefix S03_Run1.data.t.tshift S03_Run1.data.t+orig

(I used tpattern just in case, although as far as I understand I don’t have to?)
Now when asking for slice timing info with 3dinfo - I get a vector of all zeros. So I assume slice timing now works, right?

In any event, I would be happy to know how I can skip the 3dTcat, and just call the tpattern file with 3dTshift. Thanks!

5

Hi Galit,

It is correct not to have any slice timing information in the output, since that is the purpose of running 3dTshift. Your example with running 3dTshift -tpattern looks fine.

Look at the text output from running the program. You can add the -verbose option to have it specify the offsets being used.

  • rick
6

Hi Rick,
I oculdn’t find a way to verify that slices were indeed time shifted. I tried looking at the dataset with 3dinfo, with the verbose option, but couldn’t find a vector that specifies the shifts.
I assume that it does work, but just for the purpose of self verification I think it is better to apply the vector with 3dTcat, so that I can compare input and output.
Thanks,
Galit

7

Consider comparing use of 3dTcat to not. The results should be identical.

The -verbose option is for 3dTshift, for it to say how much it is shifting by.

  • rick
8

Oh, I see. Great, thanks!