 |
 |
Hi again, This has been a very useful discussion for me as well. To answer the question, yes I am specifically doing this to compare FSL's processed data with Avi's 4dfp method, which performs STC as the very first step, so I was interested in your thoughts on that. 4dfp is great but has some limitations in the type of datasets it can process (i.e. monkeys, infants, etc.). So, we're transitioning towards using FSL, at least for the preprocessing. Another reason I am particularly interested in the tradeoffs of using STC, and when to use it if at all, is because we are doing functional connectivity analyses (rs-fcMRI), which are dependent upon the exact timecourses for each ROI. If STC is not applied, I am concerned that this may affect this particular type of analysis more than epoch-related fMRI. Do you think this concern is valid? This has been great, thanks to all. -David -----Original Message----- From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of Jessica Cohen Sent: Friday, December 09, 2011 12:35 PM To: [log in to unmask] Subject: Re: [FSL] pre-filtered to atlas transformed in one resampling step Oh great, thank you! -Jessica On Fri, Dec 9, 2011 at 12:29 PM, Mark Jenkinson <[log in to unmask]> wrote: > Hi, > > That's a good point about non-GLM analyses. > In many cases like that I would say that it does make > sense to use slice timing correction. > > The arguments before about the order of motion > correction and slice timing correction don't change though. > I still think it should be MC first and then STC. > > As for including motion regressors - it still makes > sense to do this and will get rid of some of the changes > not fully compensated by MC. Having STC run too will > induce some extra changes, but these will be second > order effects in general and so the standard motion > correction regressors are still be the best thing to use. > > All the best, > Mark > > > > On 9 Dec 2011, at 19:41, Jessica Cohen wrote: > >> To jump into this discussion, I was talking to a colleague about why >> slice timing correction should not be done generally. She brought up >> the point that data processed through a GLM, where you can include >> temporal derivatives, is one thing, but when you're looking at data >> outside of a GLM (i.e., a resting timeseries), you can't include >> temporal derivatives. >> >> In that case, would it make sense to use slice timing correction for >> data that was acquired in an interleaved fashion, or is there some >> other correction that could be better (or is no correction necessary)? >> And would you still recommend doing motion correction first? >> >> And regarding the order of motion correction/slice timing >> correction...when I run either a GLM or a timeseries analysis, I >> include my motion parameters as nuisance regressors. But if I did >> motion correction before slice timing correction, could I no longer do >> that because the slice timing correction has changed the structure of >> the data? >> >> Thank you for your help. This discussion has been really useful. >> >> -Jessica >> >> >> On Fri, Dec 9, 2011 at 8:43 AM, Mark Jenkinson <[log in to unmask]> wrote: >>> Hi Michael, >>> >>> I don't see that this changes it. >>> >>> The intensity difference through time (in a spatially fixed voxel) is at >>> most say 5% from BOLD (being very generous). Given how slow the >>> HRF is, then maybe the difference in intensity that you'd see between >>> timepoints that are separated by TR/2 is more than you'd see when >>> they are separated by TR/N, but it is still less than 5%. >>> >>> In contrast, or contradistinction if you prefer, the intensity difference >>> adjacent points in space can easily be 50-100% (of the mean intensity). >>> So I don't care so much about locking in incorrect timing changes by doing >>> STC second (which results in 5% change or less) if it means I can >>> correctly get rid of most of the 50-100% change in signal due to mislocation >>> in space (by doing MC first). >>> >>> Alternatively, locking in the spatial mislocation by doing STC first (and >>> so interpolating in time before correcting spatial location) could lock in >>> a reasonable amount of the 50-100% spatial change by putting it into adjacent >>> timepoints, which can then not be recovered by subsequent MC. >>> >>> Now the debatable points in the above I think relate to the fact that the >>> spatial changes are not the same in all areas of the brain (they are >>> bigger near the big intensity boundaries, but that is a lot of the cortical >>> grey matter) whereas the timing changes are consistent over whole >>> slices. So if your motion is small enough (say 10% of a voxel) then >>> you might have comparable changes due to the two effects near the >>> large intensity boundaries but less so in other places. However, I think >>> that motion is often more than this (10% of the voxel size would only be >>> 0.3mm for a 3mm voxel) and also that a lot of the cortical voxels of >>> interest would be affected by this. Therefore I still think that MC before >>> STC makes sense in the vast majority of cases, but that even better is >>> to drop STC and use temporal derivatives (although I know you will >>> not agree with the last point, but at least it prevents this annoying coupling). >>> >>> So in summary - I stand behind MC before STC (if you do STC at all) >>> even when it is interleaved slice acquisition. >>> >>> All the best, >>> Mark >>> >>> >>> >>> >>> On 9 Dec 2011, at 16:20, Michael Harms wrote: >>> >>>> 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 >>>>>> >>>>> >>>>> >>>> >>