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
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.eduwrote:
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
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
Hmm, ok. Are there no functions for doing a dilation/erosion on a surface label?
On Mon, Jul 16, 2012 at 1:14 PM, Douglas N Greve greve@nmr.mgh.harvard.eduwrote:
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
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Hi Michael,
yes, you can do this in tksurfer with a tcl script (labl_erode and labl_dilate I believe). Not sure if there is a binary to do it, but it would be pretty easy to write Bruce
On Mon, 16 Jul 2012, Michael Waskom wrote:
Hmm, ok. Are there no functions for doing a dilation/erosion on a surface label?
On Mon, Jul 16, 2012 at 1:14 PM, Douglas N Greve greve@nmr.mgh.harvard.edu wrote: 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.edumailto: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
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Douglas N Greve -
Michael Waskom