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

Reply via email to