Ah, right, we don't provide low res registered spheres. In that case, it does make sense to use -surface-sphere-project-unproject to concatenate the registration onto a sphere with the correct resolution. The file names are somewhat confusing, but I suspect the considerably more complicated filename in fs_L and fs_R is fsaverage (7?) 164k mesh registered to fs_LR, and the "fsaverage" in the same directory should be copies of the fsaverage standard sphere (not to be confused with the "fsaverage" spheres one directory up, which are actually fs_LR, not fsaverage). There are two ways to do this, but it might make more sense to generate the fsaverage5 analog of the registered sphere from the fs_L directory.
To do this, use -surface-sphere-project-unproject with fsaverage5 standard sphere as input, fsaverage 164k standard sphere as project-to (assuming all fsaverage standard spheres are aligned), and fsaverage registered to fs_LR sphere as unproject-from. You can use the resulting sphere with any left-hemisphere fs_LR standard sphere to do the resampling (for right hemisphere, you'd need to generate the equivalent separately, using the fs_R directory). I don't expect any benefit to upsampling as an intermediate step, if anything it should result in slightly more blurring in the end result. I'm not as sure what the effect would be on label files. As for the cross-hemisphere correspondence, the fact that fs_LR has it, while fsaverage does not, means that fs_LR and fsaverage can't simply be already in register for both hemispheres - I don't know if they are in register for even one of the hemispheres. Donna was explaining why we chose to have this property even though it made it slightly more involved to convert to/from fsaverage. Tim On Tue, Apr 19, 2016 at 2:26 AM, Estrid Jakobsen <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>> > [email protected] >>> > http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>> > >>> > <groupconn45_fsa5.png> >>> >>> >>> _______________________________________________ >>> HCP-Users mailing list >>> [email protected] >>> 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 [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
