I am using a MB2 sequence with a TR of 2000ms and interleaved acquisition order.
Although its up for debate whether increasing the MB factor can make slice timing correction obsolete I still like to perform slice timing correction. FSL didn’t support MB slice timing correction and I also saw some stripe-artifacts when performing the AFNI slice timing correction (see attached). I thought 3dTshift uses the slice timings from the header?
I used the following code for slice timing correction:
To add details to Peter’s request, what is the output from this?
3dinfo -slice_timing run_1+orig
Using an MB acquisition should not really matter here. Perhaps
FSL does not support it is because of the limiting nature of the
NIFTI header, which is not capable of storing general slice timing
information, it just uses codes for a few known timing patters.
I do not see what artifacts you are alluding to in the image,
though there is a single red dot, which is odd. Note that we
generally avoid Fourier interpolation (for almost anything).
Though it can make nice results and is elegant, any spikes can
cause ringing artifacts.
By default afni_proc.py uses -quintic interpolation, so spikes
cannot spread far.
Can you provide any clarity regarding the artifacts? Note that
striping is common when motion occurs, with or without 3dTshift.
Many thanks for your replies. It seems indeed that the slice timing information is limited in NIFTI headers and cannot be automatically read out in for example FSL. This is one of the reasons why I switched to AFNI. By converting the dicoms using to3d the slice timing information is preserved in the header and can be applied in slice timing corrections (see output 3dinfo -slice_timing below).
Allow me to give a better illustration of the slice timing artifacts I saw in my images. Although there are undoubtably better ways of quantifying slice timing errors I used InstaCorr to see if odd/even slices correlate more strongly with each other creating blue-red horizontal stripes. The image attached illustrates better shows how slice timing affects the images. Does this make sense?
The only processing steps applied here are dicom conversion(to3d), slice timing correction (3dTshift) and motion correction (3dvolreg).
To be more specific, it is the NIFTI format that (currently)
cannot even store that slice timing sequence. So there is
nothing in the header for FSL to read. But the AFNI format
can handle arbitrary slice timing.
That slice timing seems to have 2 sets of values, meaning 2
slices were acquired at a time.
Those images do not seem bad. The correlations make your
previous red dot clear, at least. It is hard to tell whether
there is anything to worry about here. It certainly is not
impressive.
Keep in mind that any alternating acquisition will tend to
show these types of odd/even artifacts. Motion will usually
be much more highly correlated 2 slices away than just one,
since the interleaved acquisition means the timing 2 slices
away is very close, while adjacent slices are 1/2 TR off
(1/4 TR in your case). Slice timing and motion correction
will not make that go away.
But to further evaluate this, what is the comparison against
NOT running 3dTshift? I would expect a similar pattern.
Thanks Rick, that is interesting. So motion during the acquisition of the interleaved slices will cause this ‘striping’ artifact which is therefore not eliminated by applying slice timing correction?
Previously posted image was to3d + 3dTshift + 3dvolreg
if I now omit the 3dTshift command, run to3d + 3dvolreg
and perform the instacorr without manually changing the colorscale at the exact same coordinates as in the previous image you’ll see the 'striping artifact is there too but looks slightly different (see screenshot attached). Not entirely sure what to conclude from this.
Yes. Many artifacts can lead to such striping, but motion
is liekly the main culprit.
The 3dTshift operation is supposed to synchronize signals,
which should increase correlations (due to BOLD, motion,
etc), but that depends on a given signal being spatially
consistent. In some ways motion is consistent, in some
ways not. It is the unpredictability of motion effects
that makes it so difficult to handle in FMRI data.
Also, Fourier interpolation could hurt here (which is why
we do not tend to use it). It can cause spikes to ring
through the data, which might increase correlations.
It is indeed hard to conclude much from this. As with
most options in FMRI, if they were simple, there would
be no questions, and they would not even be options…
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.
