Thanks for your responses! I didn't quite realize the upsampling involved here, and that is certainly not what I'm hoping to do with these data.
My goal is to analyze the resting-state data in reference to some (cortical) anatomical landmarks I have defined on a few subjects' original freesurfer meshes, comparing the connectivity of these landmarks within each subject. I created these labels in Freesurfer on the subjects' native surfaces. As you point out, it may be worth mapping these to the 32k mesh. If that's the case, is it possible to map a coordinate (and vertex number) from the original native inflated surface, for example, to a subject's 32k surface, and how would one do this? Otherwise, I may also just use the steps outlined in question 16 here ( https://wiki.humanconnectome.org/display/PublicData/HCP+Users+FAQ#HCPUsersFAQ-16.Ca) to get the resting-state data back into native volume space. Thanks again! Jacob On Mon, Oct 1, 2018 at 1:29 PM Timothy Coalson <tsc...@mst.edu> wrote: > As a final side note, if you have a good reason to use the native > freesurfer mesh, then to get the data back onto the vertices it originally > came from (our pipelines map to the native mesh surfaces and then > downsample to 32k, last I checked), you need to use a registered native > mesh sphere, not the original sphere. Resampling from the 91282 > grayordinates file will also result in slightly more blurring than you > would get from mapping from volume to native mesh surfaces, but since the > fMRI resolution is similar to our 91282 grayordinates (by design, we chose > the 32k sphere resolution because of this data), this effect should be > small. > > Tim > > > On Mon, Oct 1, 2018 at 3:22 PM, Timothy Coalson <tsc...@mst.edu> wrote: > >> I would also question what you hope to accomplish by using the native >> freesurfer mesh - the fMRI data doesn't have that kind of resolution, and >> the result of resampling to it means you can't compare across subjects >> without resampling again later. Surface resampling is also unlike volume >> resampling, in that it doesn't move any of the subjects data in anatomical >> space (the T1w folder contains surfaces with acpc rigid aligned anatomical >> locations - you probably just want to use the 32k midthicknesses from >> there, as opposed to the ones in MNINonLinear) - think of it as changing >> the sampling "grid" (mesh), not as a spatial warp. The trick of surface >> registration is that we can give the same mesh of samples different >> coordinates per-subject - we use the index in the mesh for the purpose of >> matching functional identity as best as we can, but the coordinates remain >> wherever that point was in the individual's anatomy. Even the coordinates >> of the individual MNINonLinear surfaces are different, both because the >> volume alignment doesn't fully match gray matter across subjects, and from >> when our estimate of functional location disagrees with a folding-based >> alignment (since aligning T1w images basically tries to align folding). >> >> FYI, the error message you are getting is because you specified the 164k >> spheres, while the 91282 grayordinate cifti data exists on the 32k mesh (so >> you would need to use the 32k spheres). >> >> Tim >> >> >> On Fri, Sep 28, 2018 at 8:20 PM, Jacob Miller <jacob_mil...@berkeley.edu> >> wrote: >> >>> Hi all, >>> >>> I am interested in performing a resting state analysis in native surface >>> space, using the surface cifti *.dtseries files. I am trying to resample >>> these files to an individual subject's native surface space using >>> -cifti-resample, but am running into trouble. When I run the following code: >>> >>> *L_template='standard.L.sphere.164k_fs_LR.surf.gii'* >>> *R_template='standard.R.sphere.164k_fs_LR.surf.gii'* >>> >>> *wb_command -cifti-resample >>> rfMRI_REST1_LR_Atlas_hp2000_clean.dtseries.nii COLUMN >>> ${SUB}.curvature.native.dscalar.nii COLUMN BARYCENTRIC CUBIC >>> ${SUB}.native.dtseries.nii \* >>> *-left-spheres ${L_template} **${SUB}**.L.sphere.native.surf.gii \* >>> *-right-spheres ${R_template} **${SUB}**.R.sphere.native.surf.gii* >>> >>> When I run this command, I get this note: *ERROR: left current sphere >>> doesn't match input cifti* >>> >>> Is this the best command to use to resample the .*dtseries.nii to the >>> native surface? If so, what is the correct current_sphere option to use? >>> Also, the command asks for a cifti_template - what should I use here for >>> the best native surface cifti template? I picked the curvature cifti >>> because I wasn't sure. >>> >>> Please let me know what you think is the best way to get the >>> resting-state surface data into native space! >>> >>> Thanks again, >>> Jacob >>> >>> -- >>> >>> Jacob Miller >>> Graduate Student, D'Esposito Lab >>> Helen Wills Neuroscience Institute (HWNI) >>> University of California, Berkeley >>> >>> https://despolab.berkeley.edu/ >>> >>> _______________________________________________ >>> HCP-Users mailing list >>> HCP-Users@humanconnectome.org >>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>> >> >> > -- Jacob Miller Graduate Student, D'Esposito Lab Helen Wills Neuroscience Institute (HWNI) University of California, Berkeley https://despolab.berkeley.edu/ _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
