Hi, Many thanks for the replies!
@Donna, thanks for the info. This is certainly good to know, but I wonder how cross-hemisphere registration affects my problem since I'm only using the left hemisphere...? @Tim, I actually don't need the individual subjects' registrations as I just want to register a single group-level map, I just used a spherical mesh from an individual to run the -metric-resample command since I couldn't find a group-level fs_LR sphere (I assumed this wouldn't make a difference, but perhaps I'm wrong?). I specifically need to register to fsaverage5 since I'd like to compare to an independent dataset in this space. Using the atlas-to-atlas registrations you referred to from the pipeline repository, I wonder if it would make sense for me to first upsample from fs_LR_32k using fsaverage.L_LR.spherical_std.164k_fs_LR.surf.gii and then downsample to fsaverage5 from there? Thanks again! Estrid On Mon, Apr 18, 2016 at 11:25 PM, Timothy Coalson <tsc...@mst.edu> wrote: > The -surface-sphere-project-unproject command is used for concatenating > registrations, and since you want to go from fs_LR to fsaverage, which is a > registration that we compute, concatenating registrations isn't the way to > get there. > > However, I don't know if we release the fsaverage registrations > per-subject (to us, they are an intermediate registration). We appear to > have atlas-to-atlas registrations available in the pipeline repository, > under global/templates/standard_mesh_atlases, the fs_L and fs_R directories > contain the fsaverage spheres registered to fs_LR as I understand it. > > Do you specifically need to be in fsaverage, or is just a simple > downsampling okay? We have lower resolutions of fs_LR, for instance 20k, > and you can also create near-arbitrary resolution spheres if you want more > control over downsampling. For some analyses, parcellation could be more > appropriate than downsampling. > > It should be noted that using the individual subjects fsaverage > registration would discard the registration improvements made by MSM (for > MSMsulc, mainly less distortion). If an atlas-to-atlas registration is > used, then the registration improvements may be retained (alignment > improvements will be retained, distortion will depend on the method used > for atlas to atlas registration), but of course will give a different > result than actually using freesurfer's registration. > > Tim > > > On Mon, Apr 18, 2016 at 9:44 AM, Donna Dierker <do...@brainvis.wustl.edu> > wrote: > >> Hi Estrid, >> >> Help from others is likely to be needed, but I can help a little. >> >> The HCP surfaces get to 32k_fs_LR mesh via the Freesurfer registration >> (?h.sphere.reg); however, the fs_LR mesh is not the same as the fsaverage >> mesh, even though it is based on it. The fsaverage left and right >> hemispheres are not in registration with one another. Vertex i in the left >> hem could be in the occipital lobe, while it could be in the frontal lobe >> in the right hem. The fs_LR mesh is in register across hemispheres -- >> vertices in left and right hems are in as close to the same place as >> registration could get them to be. This facilitates cross-hem analyses. >> >> There is a relevant script here: >> >> >> https://github.com/Washington-University/Pipelines/blob/master/PostFreeSurfer/scripts/FreeSurfer2CaretConvertAndRegisterNonlinear.sh >> >> Specifically this line i sthe one to be studied: >> >> > #Concatenate FS registration to FS --> FS_LR registration >> > ${CARET7DIR}/wb_command -surface-sphere-project-unproject >> "$AtlasSpaceFolder"/"$NativeFolder"/"$Subject"."$Hemisphere".sphere.reg.native.surf.gii >> "$AtlasSpaceFolder"/fsaverage/"$Subject"."$Hemisphere".sphere."$HighResMesh"k_fs_"$Hemisphere".surf.gii >> "$AtlasSpaceFolder"/fsaverage/"$Subject"."$Hemisphere".def_sphere."$HighResMesh"k_fs_"$Hemisphere".surf.gii >> "$AtlasSpaceFolder"/"$NativeFolder"/"$Subject"."$Hemisphere".sphere.reg.reg_LR.native.surf.gii >> >> If you're like me, it will take a few days for you to get your head >> around it. >> >> But I think something like this -- projecting to one standard surface and >> unprojecting from another -- will be the answer. It might take multiple >> hops to get there, but probably only until you get the magic spheres you >> need to make this work. >> >> I still struggle with understanding the distinction between meshes whose >> vertices are in correspondence, and ones that have differing numbers of >> vertices, but a spatially aligned with one another. >> >> Donna >> >> >> On Apr 18, 2016, at 8:47 AM, Estrid Jakobsen <ejakob...@cbs.mpg.de> >> wrote: >> >> > Dear experts, >> > >> > I'm trying to use wb_command -metric-resample to downsample a vector of >> data points from fs_LR_32k (32492x1) to fsaverage5 (10242x1) space. >> > >> > If I'm not mistaken, this should be possible without prior >> registration, because the HCP fs_LR_32k surfaces and the fsaverage5 surface >> should already be in register. I've saved my data vector as a metric gifti >> file (data.func.gii) in matlab by loading a pre-existing .gii file using >> the gifti toolbox and replacing gifti.cdata with my own data vector. I'm >> then running the following command: >> > >> > wb_command -metric-resample data.func.gii >> 100307.L.sphere.32k_fs_LR.surf.gii fsa5.lh.sphere.surf.gii ADAP_BARY_AREA >> data_fsa5.func.gii -area-surfs 100307.L.inflated.32k_fs_LR.surf.gii >> fsa5_lh.inflated.surf.gii -current-roi mask.func.gii -valid-roi-out >> roi_out.func.gii >> > >> > The command runs without errors, but the output looks strange (see >> attachment). It seems as though the neighborhood information is preserved >> but the coordinates are not, especially obvious by the medial wall mask >> being shifted anterior. I've tried running the command with and without the >> -area-surfs and -current-roi (to mask out the medial wall) options, neither >> of which seem to make any difference. >> > >> > Any suggestions as to what might be going wrong here would be very much >> appreciated. >> > Thanks! >> > >> > Estrid >> > >> > **************** >> > Estrid Jakobsen >> > PhD Student, IMPRS NeuroCom >> > Department of Neurophysics >> > Max Planck Research Group Neuroanatomy and Connectivity >> > Max Planck Institute for Human Cognitive and Brain Sciences, Leipzig >> > +49 341 9940-2423 >> > _______________________________________________ >> > HCP-Users mailing list >> > HCP-Users@humanconnectome.org >> > http://lists.humanconnectome.org/mailman/listinfo/hcp-users >> > >> > <groupconn45_fsa5.png> >> >> >> _______________________________________________ >> HCP-Users mailing list >> HCP-Users@humanconnectome.org >> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >> > > -- **************** Estrid Jakobsen PhD Student, IMPRS NeuroCom Department of Neurophysics Max Planck Research Group Neuroanatomy and Connectivity Max Planck Institute for Human Cognitive and Brain Sciences, Leipzig +49 341 9940-2423 _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
