I am working with a data set in which the raw epi data are in 4-dimensional nifti files and the t1 data in 3d nifti files. I have two sets of questions regarding what AFNI thinks about these nifti files:
I decided to first change these to BRIK/HEAD files before running them through afni_proc. When doing so, the epi files were put given the “+tlrc” tag, whereas the t1 files were given the “+orig” tag. Because both are raw files, these should both be in original space (+orig). If I try to run the nifti files directly through the afni_proc script, AFNI also believes these epi files are in Talaraich space.
Is it possible that afni falsely put the epi files into Talaraich space? If so, I know that I can use “3drefit” to force AFNI to attribute these files as in original space. Or, was there some transformation on these files of which I am not aware?
If I do go ahead and do 3drefit and run the afni_proc script, during 3dTshift I receive a warning which says that my dataset is already aligned in time (see error message below). If this is raw data, why may I receive this warning message?
++ Output dataset ./pb01.337.r01.despike+orig.BRIK
foreach run ( 01 )
3dTshift -tzero 0 -quintic -prefix pb02.337.r01.tshift pb01.337.r01.despike+orig
++ 3dTshift: AFNI version=AFNI_18.2.06 (Jul 31 2018) [64-bit]
*+ WARNING: dataset is already aligned in time!
*+ WARNING: ==>> output dataset is just a copy of input dataset
You can set AFNI_NIFTI_VIEW to “orig” (in your .afnirc file, or as an environment variable). The sform/qform_code is probably 2, which has been used to mean different things by different packages.
Your 3dTshift warning about datasets already being aligned in time suggests that the slice timing information is not included in the dataset header (this is actually pretty common). You can specify a timing pattern using:
-tshift_opts_ts -tpattern alt+z
replace the alt+z with your actual slice time information
S L I C E N U M B E R
tpattern 0 1 2 3 4 Comment
--------- --- --- --- --- --- -------------------------------
altplus 0 600 200 800 400 Alternating in the +z direction
alt+z2 400 0 600 200 800 Alternating, but starting at #1
altminus 400 800 200 600 0 Alternating in the -z direction
alt-z2 800 200 600 0 400 Alternating, starting at #nz-2
seqplus 0 200 400 600 800 Sequential in the +z direction
seqminus 800 600 400 200 0 Sequential in the -z direction
If @filename is used for tpattern, then nz ASCII-formatted numbers
are read from the file. These indicate the time offsets for each
slice. For example, if 'filename' contains
0 600 200 800 400
then this is equivalent to 'altplus' in the above example.
(nz = number of slices in the input dataset)
N.B.: if you are using -tpattern, make sure that the units supplied
match the units of TR in the dataset header, or provide a
new TR using the -TR option.
I have a question about 3dTshift.
The code is 3dTshift -tzeros 0 -quintic -prefix pb01.cxexp.r01.tshift pb00cxexp.r01.tcat+orig, but a warning: dataset is already aligned in time! output dataset is just a copy of input dataset.
My experiment is slow event-related design, so slicing timing correction is very important. Dataset: 3T Siemens, slices number: 32, scanning sequence: interleaved.
3dTshift can extract scanning sequence automatically in HEAD file?
Thanks a lot!
I don’t find any slice timing information in HEAD file, so I should use ‘-tpattern’.
However, I have two kinds of slice orders in experiment. In the first four runs, the slice order is 2, 4, 6, 8, …,30, 32,1, 3, 5, 7,…,29,31; and in the back four runs, the slice order is 31,29,27,25,…3,1,32,30,28,26,…4,2.
The script is
afni_proc.py -subj_id cl
-blocks tshift align volreg blur
-tshift_opts_ts -tpattern @slice_times*.1D
I don’t know how to extract the first slice timing file automatically in the first four runs, and how to extract the second slice timing file automatically in the back four runs in script.
Thanks a lot!
This appears to have solved the problem. Thank you!