Hi Tim, Using -surface-sphere-project-unproject followed by -metric-resample seems to have done the trick. Thanks a lot!
Estrid On Tue, Apr 19, 2016 at 11:50 PM, Timothy Coalson <[email protected]> wrote: > 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 >> > > -- **************** 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
