Hi,

On 21 Apr 2007, at 18:13, nasser kashou wrote:

> Hello All,
> I’m using a GE 3T scanner and my interleave sequence is  
> 1,3,5,...2,4,6,...  (not sure if it is bottom up or top down)  and  
> fsl's is 0,2,4,6...1,3,5,..  So apparently, these two are identical  
> because of the zero? (Q1)

That's right.

> Anyways, I ran FSL’s (0,2,4,6...1,3,5,..) and (regular up)  and  
> there were differences but not very obvious.  I also ran my own  
> slice timing file
> 1
> 3
> 5
> ...
> 23
> 2
> 4
> 6
> ...
> 22
> And the results were drastically different from the previous two.

I just compared the FEAT "interleaved" option (which uses the --odd  
option in slicetimer) with a custom file like you've just described  
and they gave identical output to each other. "regular up" gives  
different results. So I'm not sure what's going on at your end.....?

> Actually, it seemed like it was haven’t problems fitting the  
> model.  So, shouldn’t this file have given similar results to FSL’s  
> (0,2,4,6...1,3,5,..)? (Q2)
> After reading some more of the threads on slice timing.  It seems  
> like this is scanner dependent and also total slice # dependent,  
> for instance, 23 slices vs 24, may change the slice order.

If you change the number of slices in the data then everything will  
indeed be different, because that will change the definition of the  
timing of the "centre" of the TR - but this is correct - I don't  
think there's any outstanding problems with the behaviour?

> Overall, if someone doesn’t catch these differences (in my case by  
> accident). Then the slice timing can throw off their results.  My  
> next step is to run NO slice timing as it may be doing more harm  
> than good, according to Steve Smith’s thread back in 2003.  http:// 
> www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind03&L=FSL&P=R14896&I=-3 ,  
> which is copied below.
> BTW, I should point out that slice-timing-correction is not in  
> general necessarily a helpful thing to do; the slight loss of  
> temporal information (because of the necessary interpolation used  
> to achieve the time shift) may outweigh the advantage of having  
> perfect "slice timing". Furthermore, it is not very satisfying to  
> have to do the timing correction as a separate stage from the  
> motion correction; integrating these is something which we are  
> working on for the future.
> But I don’t know how relevant this is now in 2007.  Would this be  
> proper to do? (Q3)

That's still relevant, yes, nothing's changed since then.

> Finally, I would like to know exactly how the slice-timing  
> correction works.   I guess my big question is, how does it  
> interpolate the data?  Specifically, is it just shifting the model  
> timings, or is it changing the intensity values of the data  
> somehow?  If the latter, what are the intensity changes based on?   
> (Q4)

It achieves a temporal shift through the use of a sinc interpolator  
which attempts to minimise interpolation-related blurring - you  
cannot shift the data by non-integer (TR) amounts without some  
interpolation and hence some changing of the data intensities.  
However the blurring can never be fully avoided hence the comment  
about slice timing correction generally being a bad thing.

Cheers, Steve.


> Thanks
> Nasser
>
> Ahhh...imagining that irresistible "new car" smell?
> Check out new cars at Yahoo! Autos.


------------------------------------------------------------------------ 
---
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director,  Oxford University FMRIB Centre

FMRIB, JR Hospital, Headington, Oxford  OX3 9DU, UK
+44 (0) 1865 222726  (fax 222717)
[log in to unmask]    http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------ 
---