 |
 |
Hi Valeria and Jon, Did you use the file slice_timing_even_odd.txt as slice _timings_ file and the file slice_timing_odd_even.txt as slice _order_ file? I'm asking because your file slice_timing_odd_even.txt, used as a slice order file rather than a slice timings file, should work fine here (I would rename it accordingly, though). See also this thread: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1212&L=fsl&D=0&P=258614 I think the problem with your timings file is that your offsets have the wrong sign so that the data are being shifted in the wrong direction. Cheers, Kris On 13.02.2018 18:46, Valeria Oliva wrote: > Dear FSL experts, > > We are trying to perform a psycho-physiological interaction analysis and > wanted to preprocess our data with slice timing correction. Our slice > acquisition order is interleaved, with an even number of slices, > acquired on a SIEMENS scanner. We looked at the DICOM header and found > that the even numbered slices are acquired first, followed by the odd > ones, see below: > 1500,0,1575,75,1650,150,1725,225,1800,300,1875,375,1950,450,2025,525,2100,600,2175,675,2250,750,2325,825,2400,900,2475,975,2550,1050,2625,1125,2700,1200,2775,1275,2850,1350,2925,1425 > The TR was 3 seconds, with 40 slices. > > The balloon help in Feat for slice timing correction option suggests > that the correction is based on the following ordering: > 0,2,4,6,.....1,3,5,7 - which we are interpreting to mean odd followed by > even assuming zero indexing. Clearly this is not appropriate for our > data, so we used a slice timings file as attached > (slice_timing_even_odd.txt). > One thing we are interested in when processing our data is the intrinsic > data quality, which we assess from the temporal SNR calculated as > temporal mean divided by temporal standard deviation for every voxel in > the brain. We compared the tSNR from our raw data to that slice time > corrected in 2 ways: (i) with the standard Feat "interleaved" option > (i.e. wrong) and (ii) with the slice timings file (even, odd). > We find that (i) gives higher tSNR than (ii). > Why? > > Because we were worried about our interpretation of even-odd vs odd-even > (zero indexing??), we generated a second slice timing file (attached, > slice_timing_odd_even.txt) that would be appropriate for odd followed by > even. The temporal SNR from this 2nd timing file performs worst of all, > which should be reassuring apart from the fact that we would expect it > to match the Feat "interleaved" option!? > We are really confused by this and would appreciate any help with > arriving at some understanding of what's going on. > > Thanks in advance, > > Valeria and Jon >