slice-timing correction does not work with a multiband protocol

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!

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.

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?

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!

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

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

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

Oh, I see. Great, thanks!