Hi Doug, thanks for the explanation! Also --projfrac-max -.1 1 .1 is a big improvement, I think it should be good for my purposes. Feeling good about this now!
Cheers, DB _______________________________________ On 04/11/2018 12:44 PM, David Beeler wrote: > Hi Doug, thanks for the response! So it looks like my initial > transform from surface label to anatomical volume wasn't working > because my template.nii.gz and brainmask were in a different space > than the functional data I was processing. This happened because I was > taking the raw f.nii.gz, doing some transformations first, and saving > it to a file called f_reg.nii.gz. I was then trying to run > preproc-sess using the -i flag to specify this f_reg.nii.gz, but when > preproc runs mktemplate-sess it still uses f.nii.gz to make the > template, regardless of what the -i or -mcin flags say. I just added a > line in the if($DoTemplate) section of preproc-sess to have the option > of adding a -funcstem and it worked fine. I have now updated my > preprocessing to run all the commands individually instead of using > preproc-sess at all, and I'm probably going to send another message to > this list later making sure I'm doing that correctly. Additionally, > Re: "I think you could do it with a single call to mri_label2vol using > --regheader and specifying the func template." This works great! > Thanks for the shortcut. I got the surface label direct to functional > volume transform working with: mri_vol2vol --regheader --mov > $OUTPUTDIR/rh.MT.volume.anat.nii.gz --targ > $MEANFUNCDIR/meanfunc.nii.gz --o > $OUTPUTDIR/rh.MT.volume.func-regheader.nii.gz --nearest But I'm still > not entirely sure exactly what information is contained in regheader > (or where I can view this information). The reason I have been using > regheader instead of register.dof6.lta is that my functional data is > aligned to the anatomical prior to running preprocessing, and my > understanding was that using regheader would just downsample (similar > to mri_convert) and I wouldn't need to specify a registration file. Is > this a flawed understanding of regheader? Regheader assumes that the two volumes "share a RAS space". This is a little hard to explain. Each volume has some geometry information in it that determines where a voxel is in RAS (right, anterior, superior) space. --regheader assumes that the RAS space is the same, so, if the RAS for voxel in volume 1 is the samseg as that of a voxel in volume2, then they must represent the same place anatomically. If you have already resampled your functional data into the 1mm, 256^3 anatomical space, then --regheader should work ok > So transforming to functional space seems to be okay now, but > transforming back to the surface is still not perfect. I tried > mri_vol2surf --mov $OUTPUTDIR/rh.MT.volume.func-regheader.nii.gz > --regheader $SUBJID --projfrac 0.5 --interp nearest --hemi rh --o > $OUTPUTDIR/regheadersurface.nii.gz and also bbregister --s $SUBJID > --reg $OUTPUTDIR/testreg.lta --mov $MEANFUNCDIR/meanfunc.nii.gz > --init-fsl --bold mri_vol2surf --mov > $OUTPUTDIR/rh.MT.volume.func-regheader.nii.gz --reg > $OUTPUTDIR/testreg.lta --projfrac 0.5 --interp nearest --hemi rh --o > $OUTPUTDIR/testregsurface.nii.gz Which both give essentially the same > result: Original Label: > http://web.mit.edu/dsbeeler/www/images/MTlabel.png Back to Surface > Overlay: http://web.mit.edu/dsbeeler/www/images/MTpatchy.png This is > actually much better than it was, but is there a way to get rid of the > patchiness? The patchiness is caused by something else. When you run vol2surf, you can try --projfrac-max -.1 1 .1 That should reduce the patchiness. If it is still not tolerable, then let me know > Again, thanks for all the useful info! > David > ______________________________ > Hi David, I've tried to answer your questions below. > > doug > On 03/30/2018 01:48 PM, David Beeler wrote: > > Hi all, > > Sorry in advance, this is a bit of an annoying one! > > > > I am trying to use freesurfer's automatically generated MT label as a > > parcel to constrain activity measured during a functional MT > > localizer. I am currently doing my analysis in the volume and I'd like > > to transform the MT surface label into the subject's volume functional > > space (i.e. the same space as the sig.nii.gz for a particular > > contrast), take the voxels in sig.nii.gz that are within the MT label, > > and project them back onto the surface (preferably to be viewed as an > > overlay with freeview). I will eventually run the analysis on the > > surface as well (making this much less roundabout, but I also use > > volume parcels so understanding how to correctly go between the volume > > and surface is important to me). > > > > In my pipeline I start off by running preproc-sess, then I register > > and transform my preprocessed functional data (fmcpr.nii.gz) to the > > subject's anatomical (without upsampling). After doing mkanalysis and > > mkcontrast, I run selxavg on this volume. So the functional data is > > aligned with the anatomical, but still has low res dimensions. > > > > If it's not too much to ask, would it be possible to provide the > > specific commands to do all these transformations properly? I'll > > provide some of the commands I've tried below so you can see where I'm > > going wrong: > > > > First I want to transform the MT label to the functional volume. I've > > tried: > > > > mri_label2vol --subject $SUBJID --label > > $SUBJECTS_DIR/$SUBJID/label/rh.MT.label --o > > $OUTPUTDIR/rh.MT.volume.anat.nii.gz --temp > > $SUBJECTS_DIR/$SUBJID/mri/orig.mgz --identity --fill-ribbon --hemi rh > > > > ...which I would expect to put the label in high resolution anatomical > > volume space (orig.mgz), but it doesn't fill the graymatter ribbon > > nicely at all. > I would have expected this to work. Can you send a pic? I just ran it > myself, and it seemed to do ok. > > > > I then use mri_vol2vol to transform to functional/sig.nii.gz space (I > > could also just downsample with mri_convert since I've already aligned > > my sig.nii.gz to my anatomical, this gives me the same result). I am > > using regheader here, is this okay? > > > > mri_vol2vol --regheader --mov $OUTPUTDIR.rh.MT.volume.anat.nii.gz > > --targ meanfunc.nii.gz --o rh.MT.volume.func.nii.gz --nearest > > > > ...and this works pretty well, but it's a little sparse so I may need > > to dilate it with mri_morphology. I think this step is fine. > Why do this extra step? I think you could do it with a single call to > mri_label2vol using --regheader and specifying the func template. Why > are you using --regheader here instead of the register.dof6.lta? > > > > Next I use matlab to take the voxels in sig.nii.gz that are also in > > rh.MT.volume.func.nii.gz and I save that as a new volume, say > > constrainedsig.nii.gz. > You can do this with mri_mask sig.nii.gz rh.MT.volume.func.nii.gz > constrainedsig.nii.gz > > Now I want to transform constrainedsig.nii.gz to the surface. I have > > tried going directly using the register.dof6.lta generated from > > preproc-sess: > > > > mri_vol2surf --mov constrainedsig.nii.gz --reg register.dof6.lta > > --projfrac 0.5 --interp nearest --hemi rh --o > > $OUTPUTDIR/constrainedsig_surface.nii.gz > This should have worked. Try doing directly on the rh.MT.volume.func.nii.gz > > > > ... and this is in the right area, but its shape doesn't match the > > shape of the original label. So I've also tried backtracking and doing > > another vol2vol and then vol2surf with regheader: > > > > mri_vol2vol --regheader --mov constrainedsig.nii.gz --targ > > $SUBJECTS_DIR/$SUBJID/mri/orig.mgz --o > > $OUTPUTDIR/constainedsig_anatvolume.nii.gz > > > > mri_vol2surf --mov constrainedsig_anatvolume.nii.gz --hemi rh > > --regheader S02 --o $OUTPUTDIR/constrainedsig_anatsurface > > > > ...and while this ends up in the right place, it is really patchy > > (looking kind of like twisty zebra stripes). Seems to me like it has > > the wrong dimensions or something, but mri_info says it's the same > > dimensions as the volume I originally created with mri_label2vol. > > > > Any help is much appreciated, thanks! > > David _______________________________________________ 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.
