 |
 |
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 >>>>>> >>>>> >>>>> >>>> >>