I convert our DICOMS to .nii via dcm2niix and when running 3dinfo -slice_timing …/…/data/sub01/rest1.nii I got worried:
3dinfo -slice_timing ../../data/sub01/rest1.nii
** AFNI converts NIFTI_datatype=4 (INT16) in file ../../data/sub01_TF/rest1.nii to FLOAT32
Warnings of this type will be muted for this session.
Set AFNI_NIFTI_TYPE_WARN to YES to see them all, NO to see none.
0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000
To me that indicates that there is no information in the .nii file to find for the AFNI-function, right? This means that my preprocessing is just copying my data and don’t preform any slice timing corrections?
When running pre-processing on this particular dataset the output of tshift is:
That’s correct, 3dTshift does not know the slice order if they aren’t transcribed into the header. This is actually pretty common with conversion of DICOMs to NIFTI via dcm2nii or other tools.
You should use the syntax for explicitly setting the slice order, just make sure to use the correct order:
-tshift_opts_ts -tpattern seq-z
Alternatively, you can set the slice order using 3dTcat (-tpattern) or 3drefit. But I usually specify the order by hand in my afni_proc.py commands.
Adding on to Peter’s sage advice… NIFTI datasets can have slice timing information, but it’s limited to a few “slice_code” types. See the link below for more info. The AFNI format is a little more flexible is slice timing types. And to complicate this a bit more, the AFNI extension can be included inside the NIFTI header.
We have linearly collected ascending slices (feet to head) and we are confused about using -z or +z. From previous responses it sounded like -z was correct but +z (from feet to head) is how the data is collected (assuming positive z-axis from feet to head).
When using -tpattern seq-z (and the default -tzero set to 0) we expect the top slice to stay the same which is what we see: the de-spike time course and the tshift time course are identical (i.e. no shift) in the top slice. The shift occurs in the bottom slice. Since we know we start from the bottom -tpattern seq+z makes more sense. The problem here is that with +z the top slice is shifted but it is shifted to the right. The peaks move to the right in the graph. Since the top slice is collected last I would expect them to move to the left. This indicates that +z is wrong for ascending?
The -tpatern seq-z shifts the first (bottom) slice to the right which actually would make it a correct shift but it feel counter intuitive since the actual order is +z, so I would “want” to move the top slice time series to the left.
3dTshift -tzero 0 -quintic -prefix pb02.$subj.r$run.tshift -tpattern seq+z pb01.$subj.r$run.despike+orig
tzero zzz = align each slice to time offset 'zzz';
the value of 'zzz' must be between the
minimum and maximum slice temporal offsets.
-tpattern ttt = use 'ttt' as the slice time pattern, rather
than the pattern in the input dataset header;
'ttt' can have any of the values that would
go in the 'tpattern' input to to3d, described below:
seq+z = seqplus = sequential in the plus direction
seq-z = seqminus = sequential in the minus direction
Disregarding the confusion above. We expect the bottom time serie (or top) to not be affected and the top (or bottom) time series just to be shifted in some direction without changing it overall look of the time series. This is what we see. But what is supposed to happen in the middle of the stack? We would expect a smaller shift in some direction, which is kind of what we see, but we also see kind of a modulation of the look of the time series. The peaks of the BOLD signal change their shapes a bit. Is that expected? See attached despike and tshift of a slice in the middle.
Using a shift to a relative zero, at the beginning of each TR, there should be a general shift to the left for all but one of your slices. The exception is the slice that starts the TR. There are several interpolation schemes that will affect how that comes out with the general result in that the curves are smoother than the original ones.
This indicates that the Z-coordinate (or k) goes from low/neg to high/pos when travelling up the stack. Which is what i see in the viewer as well. Attaching print screen of the despike time series (top) and the tshift time series (bottom) of the most top slice. Code from the .proc:
# ================================= tshift =================================
# time shift data so all slice timing is the same
foreach run ( $runs )
3dTshift -tzero 0 -quintic -prefix pb02.$subj.r$run.tshift \
-tpattern seq+z \
pb01.$subj.r$run.despike+orig
end
# --------------------------------
# extract volreg registration base
3dbucket -prefix vr_base_min_outlier \
pb02.$subj.r$minoutrun.tshift+orig"[$minouttr]"
Something is not right, right? The peaks travel to the right.
Using alt+z with slice 0 collected first, the last slice should
indeed move to the right. The values were collected later
in time (than those in slice 0).
To put it another way, after the tshift operation, it is as if
each entire volume were acquired at the time of slice 0.
So that first spike in the last slice does not happen until
basically the next time point. This looks appropriate.
That’s good! It felt kind of counter intuitive but I get it now!
Thanks Rick!
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
