There is not an easy/good way to handle this situation. The way it works is that it goes through each point in the source and finds the closest vertex in the target. If the target is more densely sampled, then there are some points in the target in the middle of the label that are not the closest vertex to any label vertex in the source. It is hard to figure out computationally whether an unlabeled point is in the middle of the label or halfway around the brain. One thing that might work ok is to save the output as a binary mask (--outmask), then smooth it a little (mris_fwhm or mri_surf2surf), then re-binarize the mask (mri_binarize), then convert it to a label (mri_cor2label --i smoothed-and-binarized.mgh --id 1 --surf yoursubject lh white --o lh.label.yoursubject).
doug
On 07/16/2012 03:30 PM, Michael Waskom wrote:
Hi, just wanted to bump this up since it looks like Doug is back.
On Tue, Jul 10, 2012 at 5:09 PM, Michael Waskom <mwaskom@stanford.edu mailto:mwaskom@stanford.edu> wrote:
Hi, I'm using mri_label2label to reverse normalize labels from fsaverage space to the native surface. I'm ending up with some splotchy-looking labels, for lack of a better word. See what I mean here: http://web.mit.edu/mwaskom/www/splotchy.png I'm doing this normalization in a script with the following relevant line, which seems to be what happens inthe BAlabes step of recon-all mri_label2label --srclabel ../fsaverage/label/${hemi}.${roi}.label \ --srcsubject fsaverage --trgsubject ${subj} \ --trglabel label/$hemi.${roi}.label \ --regmethod surface --hemi $hemi Any idea how I can avoid this splotchiness or, failing that, do a closing on the label to clean up some of the noise? Cheers, Michael
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer