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
