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 > _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
