Thank you for your explanation. I have a little bit confused. As the third way of registration you mentioned, why could we simply apply the motion correction for fMRI volume data and align to T1 image with bbr, then project to fs32k native surface as one step registration, couldn't we? If not, how was this motion correction warpfield for each fMRI volume involved in current registration pipeline (native volume --> MNI space --> template surface)? Did I miss something?
Best, Ting On Mon, Mar 2, 2015 at 9:52 PM, Glasser, Matthew <glass...@wusm.wustl.edu> wrote: > This is a good point and something we thought about at the time. The > reason we did it this way was to avoid having to generate two separate > volume timeseries files (making these is by far the most time-consuming > part of the fMRIVolume pipeline). We would have had to make one that was > fully distortion corrected, but put into native T1w space with a single > resampling step and another (the only one that we currently make) that is > put into MNI space with a single resampling step. > > There was a third way this could have been done (much more complicated, > but without the single spline interpolation step in the volume): We could > have applied the volume warpfield for each fMRI timeseries volume to the > native mesh surfaces to make many copies of them (because of the motion > correction there is a unique warpfield for each fMRI volume) and resampled > onto the surfaces directly from the original fMRI timeseries. This also > would have been more exact because while volumes must be resampled after > registration to a voxel grid, surfaces can have the transformations applied > to their vertex coordinate positions exactly (in mm). Coding this up would > have been a bit of a challenge (and slower), as things like the high local > COV exclusion expect the surface not to move around and thus would also > have to be computed for every fMRI volume. Perhaps if computers get faster > and someone gets bored enough to bother, this will get implemented… > > Peace, > > Matt. > > From: ting xu <xutin...@gmail.com> > Date: Monday, March 2, 2015 at 8:30 PM > To: Matt Glasser <glass...@wusm.wustl.edu> > Subject: The minimal preprocessing pipelines for HCP > > Dear Dr. Glasser, > > My name is Ting Xu and I am a postdoc from Nathan Kline Institute, New > York state. I am writing to enquire about the order of preprocess steps in > HCP pipeline. > > I read the pipeline scripts and noticed that the order of preprocess for > surface data is (1) registered native volume to MNI volume using fnirt, (2) > applied the fnirt registration to native surface, (3) project data from > volume to surface in MNI space, (4) registered the data to fs32k template. > > There is another way for registration, e.g. project the data from native > volume to native surface then register to fs32k template. > > I was wondering why should we bring the the data to MNI space for both > native volume and surface first, and then do the projection in MNI space? > Would you please tell me are there any specific reasons behind this? Many > thanks for your comments! > > > Warmly regards, > > Ting > -- > > Xu,Ting > Postdoc > Nathan Kline Institute, Child Mind Institute > Laboratory for Functional Connectome and Development (LFCD), Institute of > Psychology, CAS > > > > ------------------------------ > > The materials in this message are private and may contain Protected > Healthcare Information or other information of a sensitive nature. If you > are not the intended recipient, be advised that any unauthorized use, > disclosure, copying or the taking of any action in reliance on the contents > of this information is strictly prohibited. If you have received this email > in error, please immediately notify the sender via telephone or return mail. > _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
