Hi Mark,
For the benefit of the list, do you think that your argument that MC
should be applied before STC (if applied at all), applies equally to
both interleaved and sequential acquisitions?  For sequential
acquisitions, MC before STC does seem to be the logical choice, since
any error in STC from applying MC beforehand is going to be small.
However, for interleaved acquisitions, the STC error from applying MC
first will be larger (because adjacent slices are acquired TR/2 apart in
time, rather than TR/Nslices in time).

I know its hard to quantify the trade-offs, but when talking about the
ordering of STC vs. MC, I think the issue of sequential vs. interleaved
acquisitions is a key distinction that needs to be considered in the mix
as well.

Cheers,
-MH

Since we've talked about this off-list, do you

On Fri, 2011-12-09 at 06:53 +0000, Mark Jenkinson wrote:
> Hi,
> 
> 
> If you want to include STC then that is fine, but make sure you do it
> *after*
> motion correction, not before.  Otherwise you'll lock in incorrect
> spatial
> locations into neighbouring timepoints (due to STC) and motion
> correction
> will be unable to fix this.  This is much worse than locking in
> temporal shifts
> into the wrong voxels as the spatial changes can be up to 100% of the
> mean intensity whereas temporal changes are normally only about 1%.
> I know that some other people argue that STC (when it is done at all)
> should
> be before motion correction but I strongly believe that this is wrong
> because
> of the above argument, and stops motion correction removing some
> bigger
> intensity changes, which is far worse than stopping STC from mopping
> up
> some tiny changes.
> 
> 
> All the best,
> Mark
> 
> 
> 
> 
> 
> On 9 Dec 2011, at 00:13, David Grayson wrote:
> 
> > I see, thanks for your response Mark. If it was imperative to
> > include STC, though, say to compare with other data that had been
> > processed that way, would it still be appropriate to apply it as a
> > first step?
> >  
> > Thanks,
> >  
> > -David
> >  
> > From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On
> > Behalf Of Mark Jenkinson
> > Sent: Thursday, December 08, 2011 12:30 AM
> > To: [log in to unmask]
> > Subject: Re: [FSL] pre-filtered to atlas transformed in one
> > resampling step
> >  
> > Dear David,
> >  
> > Unless you do no smoothing it is unlikely that you would see a lot
> > of benefit
> > from this kind of combination.  We do try and reduce the number of
> > steps as
> > it is, so you would, at most, get rid of one intermediate.
> >  
> > We also do not recommend slice-timing correction in general, and
> > would
> > advocate using temporal derivatives in the GLM instead.  Partly
> > because of
> > this, our slice-timing-correction tool is not quite as well
> > integrated, and I
> > do not think it would be possible with the existing tools to combine
> > this as
> > a transformation that is applied simultaneously with the other
> > spatial
> > transformations.  So I'm sorry, but I think the answer here is that
> > you cannot
> > do this, but for the reasons above I personally do not think it is
> > important.
> >  
> > All the best,
> >             Mark
> >  
> >  
> > On 8 Dec 2011, at 01:17, David Grayson wrote:
> > 
> > 
> > 
> > Hi,
> >  
> > There have been some posts on the listserv about this previously –
> > what I’d like to do is apply all the feat pre-stats steps in one
> > command, to achieve all the preprocessing in one resampling step,
> > instead of multiple stages. It has been argued that this *may*
> > improve power for later analyses, and I think I know how to
> > implement this…
> >  
> > But my question is this: where then would I apply slice-timing
> > correction? FSL’s standard procedure is to apply it right after mc
> > and fieldmap-correction, but then I’m back to resampling my data
> > more than once; is it equivalent to do slice-timing correction as
> > the very first step instead?
> >  
> > Thanks for any insights,
> >  
> > David
> >  
> 
>