Let me try to clear up some confusion: To answer the original question, the "area correction" that the minimal preprocessing pipelines paper refers to for smoothing and resampling surface data makes use of the individual's midthickness surface, not a group average, for the reasons I previously mentioned and Donna reiterated. The vertex areas and distances are thus always different for every subject.
Figure 20 in the minimal preprocessing paper should help explain where each mesh is involved, it always uses the subject's surface (which is resampled to have versions on each mesh) - the resampling between subject's native surface and the fs_LR 32k mesh uses the subject's native midthickness and 32k midthickness to derive the vertex areas used (side note: the 32k midthickness surface is currently generated by resampling with a simple barycentric method, as coordinate data has a different nature, in that added smoothness is harmful). Smoothing then takes place on the subject's 32k midthickness surface, using it for both vertex areas and geodesic distances. Donna was talking about a certain correction we do when we are forced to use a group average surface for processing, for further analysis that has to be done after group averaging the data (this doesn't happen inside the minimal preprocessing as far as I know) - this is why she referred to cluster tests. It is related to why we use individual surfaces whenever possible, but it is not a perfect correction, so it should not be used as a substitute when it is feasible to do the computation on the individual's surface. Tim On Fri, Nov 21, 2014 at 11:43 AM, Glasser, Matthew <glass...@wusm.wustl.edu> wrote: > Vertex areas are used in resampling from the native mesh to the 32k > registered mesh (this process occurs on the sphere and aside from the > vertex areas which are calculated on the subjects native mesh and 32k > registered mesh midthicknesses the midthicknesses are not involved). > > The small amount of smoothing that is done (2mm FWHM) is done on the > subject¹s 32k registered midthickness. > > Conte69 is a group average midthickness that applies to a specific group > of subjects (69 normal controls from the Conte center that we used in the > original T1w/T2w myelin mapping study). > > The 32k registered mesh is called 32k_fs_LR (this appears in the file > names of many of the datasets) and refers to a particular surface > topology. > > The registration is geographically aligned (in terms of rotation of the > data on the sphere) to a left/right landmark alignment that David did of > the fsaverage surfaces. > > Any of the HCP functional CIFTI data can be displayed on any 32k_fs_LR > surface. > > The distances between the vertices are not the same across all subjects, > the only thing that is the same is the correspondence between the vertices > (I.e. Vertex 1000 means the same thing across subjects, in so far as the > registration was accurate). > > Peace, > > Matt. > > On 11/21/14, 10:27 AM, "Donna Dierker" <do...@brainvis.wustl.edu> wrote: > > >If you compute areas on subject's native mesh, then generally correction > >is not necessary. But if you compute areas on a mean midthickness > >surface, for example (e.g., computing supratheshold area on group-derived > >clusters/parcels), then correction is appropriate. > > > >The smoothing to which Tim refers is when you have a bunch of > >midthickness surfaces, for example, and you average them to create a mean > >midthickness. The areas of high variability get smoothed out, so they > >are not as deep/folded as the individual was, hence distances are shorter > >on the mean surface. Averaging occurs on the atlas mesh -- not native > >mesh. And Tim is advising you NOT to compute areas/distances on the mean > >midthickness, if you can figure out a way to do it on the individuals. > >This might entail bringing some group-derived ROI (e.g., label.gii) to > >your individual's atlas midthickness (e.g., 164k or 32k mesh surf.gii). > > > >The dtseries.nii files do not contain geometry information. They link to > >surf.gii files through the mesh they share. You should pair the > >individual's dtseries.nii with the corresponding midthickness surf.gii. > >Leave the Conte69 geometry out of it, for purposes like these (unless you > >have only group dtseries.nii, in which case you need a mean midthickness > >with vertex-areas). The distances between the same vertex pairs differ > >quite a bit across subjects. > > > >Regarding the vertex areas, could you provide a link to the pipeline > >source in github where this is invoked in the pipeline? Few people are > >familiar with this enough to know, but others might be able to shed some > >light if we see how it is called. I've only seen this feature used when > >dealing with group data, but I'm sure there are usages of which I am > >unaware. > > > > > >On Nov 21, 2014, at 8:59 AM, Benjamin Risk <bb...@cornell.edu> wrote: > > > >> Great, thank you for the information! To clarify, does the smoothing > >>and area correction occur on the native mesh or Conte69? Do the cortical > >>data in a task file .dtseries.nii correspond to Conte69 midthickness, > >>i.e., the distances between and areas of the vertices are the same for > >>all subjects? > >> > >> Thanks again! > >> Ben > >> > >> On Thu, Nov 20, 2014 at 6:12 PM, Timothy Coalson <tsc...@mst.edu> > wrote: > >> No, we do not have a precomputed file of geodesic distances, we compute > >>them on the fly in any operation that needs them. Using the > >>-surface-geodesic-distance command on each vertex of interest is > >>certainly one way to find these distances, and may be the best available > >>way depending on the language or tools you intend to use for further > >>analysis. However, you should use individual surfaces when processing > >>an individual's data, as averaging the surfaces of a group of subject > >>results in smoothing out folding patterns, with more smoothing in higher > >>variability areas, which changes the distances in undesirable ways. > >> > >> The -surface-vertex-areas command does indeed output the vertex areas > >>as they are used in our processing. Again, you should use individual > >>surfaces when possible. > >> > >> If you want to see how we compute these, the most relevant starting > >>points are here: > >> > >> > >> > https://github.com/Washington-University/workbench/blob/master/src/Files/ > >>SurfaceFile.cxx , search for "computeNodeAreas" > >> > >> > https://github.com/Washington-University/workbench/blob/master/src/Files/ > >>GeodesicHelper.h > >> > >> Tim > >> > >> On Thu, Nov 20, 2014 at 4:30 PM, Benjamin Risk <bb...@cornell.edu> > >>wrote: > >> Hello, > >> > >> I am trying to define a neighborhood structure for vertices in the > >>cortical surface used in the fMRISurface pipeline. My understanding is > >>that the minimally preprocessed subject data are spatially matched to > >>the 32k Conte69 midthickness surface. I would like to use the same > >>distance structure that was used in the preprocessing pipeline as > >>described in Glasser et al (2013) p.121 paragraph two. Does a 32k x 32k > >>matrix (or 29k x 29k excluding medial wall) of distances between > >>neighboring vertices already exist (e.g., sparse matrix with distances > >>for vertices within 3 sigma defined using a 2mm FWHM Gaussian kernel)? > >>If not, is the best way to generate such a matrix by looping through the > >>vertices and using the wb_command -surface-vertex-areas with limit set > >>to 3*0.8493 or similar? > >> > >> On a separate note, I am also interested in the "vertex areas" used in > >>the pre-processing pipeline. Does the command below reproduce these > >>areas? > >> > >> wb_command -surface-vertex-areas > >>Conte69.R.midthickness.32k_fs_LR.surf.gii myfile.gii > >> > >> > >> Many thanks! > >> Ben Risk > >> > >> Graduate Student > >> Department of Statistical Science > >> Cornell University > >> _______________________________________________ > >> HCP-Users mailing list > >> HCP-Users@humanconnectome.org > >> http://lists.humanconnectome.org/mailman/listinfo/hcp-users > >> > >> > >> > >> _______________________________________________ > >> HCP-Users mailing list > >> HCP-Users@humanconnectome.org > >> http://lists.humanconnectome.org/mailman/listinfo/hcp-users > >> > > > > > >_______________________________________________ > >HCP-Users mailing list > >HCP-Users@humanconnectome.org > >http://lists.humanconnectome.org/mailman/listinfo/hcp-users > > > ________________________________ > 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 > _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
