Hi Doug, OK, just one last question! I've decided I'd rather use the smaller masks (generated by resampling aparc+aseg.mgz to functional space, as in my Method 1), since the difference is small (~2%), but there's absolutely no overlap in this case. Thus it's both the most conservative approach and easiest to match up with the analyses I've already conducted using these masks outside of fs/fsfast.
The only problem is that there doesn't seem to be an obvious way to use these masks with func2roi-sess...I can produce labels from my masks, but they are in native functional space, and as I understand it func2roi-sess expects the .label file to be in the subject's 1mm^3 anatomical space (or tal). It seems I could "trick" func2roi-sess into using my masks as if they are functional contrast stat maps, but will this work? I.e., something like this: func2roi-ses -maskanalysis DummyMaskAnalysis -maskcontrast Mask1 -maskmap Mask1.nii.gz -maskthresh 0.5 [...etc.] Since I've set the threshold at 0.5 and the mask is binary, only my voxels should pass through. I tested this out and it actually ran with this "dummy" directory structure properly formed...Is there any obvious problem with this? (slash, obviously better way to do this?) Thanks a lot for your help. Best, Tim On Fri, Aug 20, 2010 at 4:34 PM, Douglas N Greve <gr...@nmr.mgh.harvard.edu>wrote: > you can play around with the fill threshold > > doug > > Timothy Vickery wrote: > >> I see, thanks for the quick clarification. So in the Method 2 there is a >> chance that some voxels will show up in multiple ROIs, right? Is there a >> modification of Method 2 that maximizes that number of labeled voxels while >> ensuring that they will not show up in multiple ROIs? >> >> Thanks again, >> Tim >> >> >> On Fri, Aug 20, 2010 at 4:15 PM, Douglas N Greve < >> gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>> wrote: >> >> The difference is the partial volume correction is different if >> there are a bunch of other labels there (aparc+aseg) vs only one label >> >> doug >> >> Timothy Vickery wrote: >> >> Hi all, >> >> I'm creating binary mask volumes in a subject's native >> functional space from the segmented brain in aparc+aseg.mgz >> (FS v 4.5). I have found that doing this two different ways >> produces different results, and I'm wondering if anyone can >> illuminate why this might occur and which method is more >> appropriate (or what other method you would suggest)... >> >> Method 1: Resample aparc+aseg.mgz into native functional space >> using >> mri_label2vol --seg aparc_aseg.mgz --fillthresh 0.5 [...plus >> the rest of the appropriate inputs such as subject's >> bold/register.dat] >> >> Then I just parse the resulting image (using matlab or python >> code) into separate binary masks for each unique identifier >> that I'm using...E.g., for right IPL I load this image and >> create a new volume [newVol = (oldVol==2008)] and save that out. >> >> Method 2: Create a label file from aparc+aseg.mgz for each >> unique identifier that I'm using, and then use mri_label2vol >> to produce a binary mask in native functional space: >> mri_cor2label --i aparc+aseg.mgz --id 2008 --l rIPL.label >> mri_label2vol --label rIPL.label --fillthresh 0.5 [... plus >> the rest of the required inputs, same as those used in Method 1] >> >> Even though these seem like they should be equivalent to me, >> and although the masks produced agree for the most part, I >> generally get several more voxels per ROI using Method 2 than >> I do using Method 1 (and not complete overlap otherwise). For >> instance, for one subject, Method 1 yields 308 voxels in rIPL, >> but Method 2 yields 316 voxels; disagreement between the two >> occurs in a total of 26 of those voxels, so it isn't just a >> matter of Method 2 being more generous. The discrepancy seems >> to be proportional to the size of the ROI, so I get just a >> handful of disagreements for smaller ROIs (but it seems to >> happen almost all the time). >> Thanks for any advice on which method is better, or a >> suggestion of a better method. >> >> Best, >> Tim >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu >> <mailto:Freesurfer@nmr.mgh.harvard.edu> >> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> -- Douglas N. Greve, Ph.D. >> MGH-NMR Center >> gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu> >> >> Phone Number: 617-724-2358 Fax: 617-726-7422 >> >> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >> >> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >> >> >> > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > gr...@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.
