It's definitely not a strategy I'd have come up with on my own. I always wondered why one would want to disconnect a set of nodes.
thanks very much indeed. Colin On 22 July 2012 04:40, <[email protected]> wrote: > Send caret-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://brainvis.wustl.edu/mailman/listinfo/caret-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of caret-users digest..." > > Today's Topics: > > 1. Re: caret-users Digest, Vol 106, Issue 18 (David Van Essen) > > > ---------- Forwarded message ---------- > From: David Van Essen <[email protected]> > To: "Caret, SureFit, and SuMS software users" < > [email protected]> > Cc: > Date: Sat, 21 Jul 2012 22:38:38 -0500 > Subject: Re: [caret-users] caret-users Digest, Vol 106, Issue 18 > Colin, > > You might consider the following. > > Draw borders around the medial wall (as you've already done), and paint as > many nodes as you can as 'medial-wall'. > > Select Surface ROI: Paint: medial-wall, then select ROI operation: > disconnect selected nodes. > > Go back to Surface ROI and select Remove Islands. > THis should remove ALL of the medial wall, unless there is a 'finger' that > connects some interior medial wall to the rest of cortex. > > If there is such a finger, use Surface: Cuts: Draw cuts to make a full > disconnect, then repeat the remove islands step. > > This should get you a surface in which ALL medial-wall nodes are > disconnected. > > Save the topology file as ***.open.topo > > Then select all (non-medial-wall) nodes and give them all some interim > assignment. (e.g. 'temp-cortex') in a new paint column. The remaining > unassigned nodes (all '???') should constitute a 'true' medial-wall.'' > Save this paint file approrpiately. > > Return to a surface in which you have the original closed topo file. > Using Surface ROI, select the '???' nodes from the above paint file. If > they constitute all of the true medial-wall nodes, then you should be able > to smooth them all and achieve your objective. > > Believe me, I recognize that the devil's in the details. I'm not certain > that this will work, but I suspect that it (or some variation therof) will > finally get the job done for you. > > David > > > On Jul 21, 2012, at 3:18 PM, Colin Reveley wrote: > > the only thing that works without making a new surface is smoothing > operations on parts of the ROI, strategically, till smoothing on the wole > thing might work > > but this is also tricksy. it's generally easier to to do by hand altering > the segmentation to remove the biggest issues. this applies to surfaces > made in caret with surefit as well as FS stuff, although less so. > > On 21 July 2012 21:09, Colin Reveley <[email protected]> wrote: > >> in may cases it is very, VERY hard to paint the apropriate subset of >> nodes, if the geometry is truly complex. >> >> one must use many little borders instead of one large one. >> >> even if you do get all the nodes painted, smoothing operations won't work >> out in these situtations. >> >> this isn;t a niave question, to which the standard solutions apply. I've >> spent probably hundreds of hours on this issue. it is very hard. It may >> well only come in in ex-vivo. >> >> caret has problems with painting by border enclusure, and with smoothing, >> when the geometry of the set of nodes is really complex, convex, concave, >> and folder UNDER itself (but still homeomophic to a sphere) >> >> I thought you guys probably knew that. >> >> On 21 July 2012 18:00, <[email protected]> wrote: >> >>> Send caret-users mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> or, via email, send a message with subject or body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of caret-users digest..." >>> >>> Today's Topics: >>> >>> 1. Re: part of a surface (Donna Dierker) >>> 2. Re: part of a surface (David Van Essen) >>> 3. Re: Freesurfer Surface and Volume are not in register when >>> shown in Caret (Pablo Polosecki) >>> 4. Re: Freesurfer Surface and Volume are not in register when >>> shown in Caret (David Van Essen) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Donna Dierker <[email protected]> >>> To: "Caret, SureFit, and SuMS software users" < >>> [email protected]> >>> Cc: >>> Date: Fri, 20 Jul 2012 18:18:51 -0500 >>> Subject: Re: [caret-users] part of a surface >>> On Jul 20, 2012, at 5:06 PM, Colin Reveley wrote: >>> >>> > Is it possible to inflate just part of a surface? I doubt it. >>> >>> Inflate, I don't think so; smooth -- definitely. You can use paint to >>> select nodes, then constrain the smoothing that way. >>> >>> I don't have caret handy, but look at the options under Surface: >>> Geometry. >>> >>> > >>> > I am experiencing my usual agony in smoothing the medial wall of my >>> surfaces. as you can see, the medial wall region is very complicated and >>> hard to make into a smooth sheet, with big convexities, big concavities, >>> and loads of smaller ones. >>> > >>> > Actually I can't even make a crossover free sphere from this one. >>> > >>> > yes, I can change my segmentation by hand. but at the risk of losing >>> accuracy. altering the segmentation is normally what I do. aside from being >>> a bit dodgy, it's also very laborious. >>> > >>> > another way is to smooth it piecemeal, but this example is probably >>> too far gone for that. >>> > >>> > can't I just suck those nodes out of there?! >>> > >>> > best, >>> > >>> > Colin >>> > <capture.jpg>_______________________________________________ >>> > caret-users mailing list >>> > [email protected] >>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: David Van Essen <[email protected]> >>> To: "Caret, SureFit, and SuMS software users" < >>> [email protected]> >>> Cc: >>> Date: Fri, 20 Jul 2012 18:20:54 -0500 >>> Subject: Re: [caret-users] part of a surface >>> Colin, >>> >>> First, assign your medial wall nodes to a paint (label) identity. If >>> you haven't done this already, it can be done using Draw Borders and >>> filling in the ROI, starting with a very inflated or spherical surface. If >>> you have crossovers in your medial wall, this might take some futzing and >>> an extra round, but I think it can be made to work. >>> >>> Then use Surface: Surface ROI: Node Selection: Paint, and select the >>> medial wall nodes, but starting with the midthickness configuration in the >>> main window. >>> Then use ROI Operation: Smoothing, and choose parameters that yield >>> adequate smoothing. >>> >>> If you have crossovers initially, you can probably re-inflate and >>> re-project to the sphere starting with the partially smoothed medial wall. >>> >>> Good luck. >>> >>> David >>> >>> >>> On Jul 20, 2012, at 5:06 PM, Colin Reveley wrote: >>> >>> > Is it possible to inflate just part of a surface? I doubt it. >>> > >>> > I am experiencing my usual agony in smoothing the medial wall of my >>> surfaces. as you can see, the medial wall region is very complicated and >>> hard to make into a smooth sheet, with big convexities, big concavities, >>> and loads of smaller ones. >>> > >>> > Actually I can't even make a crossover free sphere from this one. >>> > >>> > yes, I can change my segmentation by hand. but at the risk of losing >>> accuracy. altering the segmentation is normally what I do. aside from being >>> a bit dodgy, it's also very laborious. >>> > >>> > another way is to smooth it piecemeal, but this example is probably >>> too far gone for that. >>> > >>> > can't I just suck those nodes out of there?! >>> > >>> > best, >>> > >>> > Colin >>> > <capture.jpg>_______________________________________________ >>> > caret-users mailing list >>> > [email protected] >>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Pablo Polosecki <[email protected]> >>> To: "Caret, SureFit, and SuMS software users" < >>> [email protected]> >>> Cc: >>> Date: Fri, 20 Jul 2012 19:27:48 -0400 >>> Subject: Re: [caret-users] Freesurfer Surface and Volume are not in >>> register when shown in Caret >>> Hi Donna, >>> >>> Your excerpts were really inspiring. Many many thanks. I got them >>> finally well-alligned. >>> One more question: My volumes and surfaces have a nominal resolution >>> of 1mm but they are actually .5mm (This means we scan at .5 mm >>> resolution but we have to trick FreeSurfer into thinking we scan at >>> 1mm because it doesn't display things correctly with other resolution >>> values). Does this matter for working in Caret and registering to F99? >>> Or do I have to rescale all my files back to .5mm? >>> >>> Thanks! >>> Pablo >>> >>> On Fri, Jul 20, 2012 at 5:12 PM, Donna Dierker <[email protected]> >>> wrote: >>> > Sorry I'm not as familiar with that script, but I am familiar with >>> scripts we use for importing human freesurfer files into Caret. Hopefully >>> these excerpts might help: >>> > >>> > #Find c_ras offset between FreeSurfer surface and volume and generate >>> matrix to transform surfaces >>> > MatrixX=`$FreeSurferInstallationDirectory/bin/mri_info --cras >>> $InputFreesurferSubjectDirectory/mri/orig.mgz | cut -f1 -d' '` >>> > MatrixY=`$FreeSurferInstallationDirectory/bin/mri_info --cras >>> $InputFreesurferSubjectDirectory/mri/orig.mgz | cut -f2 -d' '` >>> > MatrixZ=`$FreeSurferInstallationDirectory/bin/mri_info --cras >>> $InputFreesurferSubjectDirectory/mri/orig.mgz | cut -f3 -d' '` >>> > Matrix1=`echo "1 0 0 ""$MatrixX"` >>> > Matrix2=`echo "0 1 0 ""$MatrixY"` >>> > Matrix3=`echo "0 0 1 ""$MatrixZ"` >>> > Matrix4=`echo "0 0 0 1"` >>> > MatrixCRAS=`echo "$Matrix1"" ""$Matrix2"" ""$Matrix3"" ""$Matrix4"` >>> > >>> > for Surface in white pial ; do >>> > caret_command -surface-apply-transformation-matrix >>> $OutputRootDir/$Subject/$InitialMeshDirectory/$Subject.$Hemisphere."$Surface"_orig.initial_mesh.coord.gii >>> > >>> >>> $OutputRootDir/$Subject/$InitialMeshDirectory/$Subject.$Hemisphere.initial_mesh.topo.gii >>> $OutputRootDir/$Subject/$InitialMeshDirectory/$Subject.$Hemisphere."$Surface"_orig.initial_mesh.coord.gii >>> -matrix $MatrixCRAS >>> > done >>> > >>> > Also, it might matter which volume you use (e.g., orig.mgz vs others). >>> > >>> > >>> > On Jul 20, 2012, at 3:55 PM, Pablo Polosecki wrote: >>> > >>> >> Hi Donna, >>> >> >>> >> I tried converting to RAS (this converst the heder information, which >>> >> apparently Caret does use) and the data matrix. The problem is the >>> >> same: the axes are correct (i.e., R points to the right side, D is >>> >> dorsal, etc). However, the surface and the volume still don't match in >>> >> Caret just like before. The issue seems to be some sort of offset in >>> >> the center of coordinates (when I click on the surface, the >>> >> highlighted points seem to be on a sensible medio-lateral and >>> >> dorso-ventral position. The problem is that the highlighted voxel is >>> >> too posterior in the volume view). Does this make sense or hint to a >>> >> possible solution to you perhaps? Worst case scenario, I could eyeball >>> >> how big this translation offset is, open the volume in matlab and have >>> >> it translate the data matrix. That way, it would roughly look okay, >>> >> but perhaps there is a more graceful way of handling this. >>> >> Thank you again, >>> >> Pablo >>> >> >>> >> On Fri, Jul 20, 2012 at 3:14 PM, Donna Dierker < >>> [email protected]> wrote: >>> >>> Be aware that what AFNI/Caret calls LPI, Freesurfer calls RAS. ;-) >>> >>> >>> >>> Can you try having mri_convert write the volume out as RAS, instead >>> of >>> >>> LPI? Freesurfer will read the header and do the right >>> flipping/rotating >>> >>> so that the surface aligns with it. Freesurfer did the right thing, >>> as it >>> >>> understands that label. But that understanding is not what other >>> software >>> >>> desires, in this case. (At least that's my read of your problem.) >>> >>> >>> >>> I think the axes don't need rotating anymore, but all three need >>> flipping. >>> >>> >>> >>>> Dear List, >>> >>>> >>> >>>> I successfully completed the FS-to-F99 tutorial and now I am trying >>> to >>> >>>> reproduce the steps with my own FreeSurfer dataset. According to the >>> >>>> FS-to-F99 tutorial, I need to have my mri volume "into LPI >>> >>>> orientation" and "the surfaces and volume need to be in register". >>> My >>> >>>> original volume is in LIA orientation and is in register with my >>> >>>> surface, in the sense that when I open both on FreeSurfer's tkmedit >>> >>>> they are well-aligned to each other (I don't know how to check that >>> >>>> they are in register otherwise). If I use this surface and volume on >>> >>>> FS-to-F99's Stage-1 script and open the resulting spec file with >>> >>>> Caret, the volume's axes are wrong and the points on the surface and >>> >>>> in the volume don't match (I see this by clicking on the surface and >>> >>>> looking what is then highlighted on the volume window). If I >>> transform >>> >>>> the volume into LPI orientation (using FreeSurfer's mri_convert >>> >>>> command), the new volume has the desired orientation and, >>> >>>> interestingly, it is still well-aligned to the surface in >>> FreeSurfer's >>> >>>> tkmedit. However, when I use this surface and volume on the >>> FS-toF99's >>> >>>> Stage-1 script, the volume and the surface are still not >>> well-aligned, >>> >>>> even though the axes labels are now correct. How could I fix things >>> so >>> >>>> that my volume and surface are in register when shown in Caret? >>> >>>> >>> >>>> Thank you very much, >>> >>>> Pablo >>> >>>> _______________________________________________ >>> >>>> caret-users mailing list >>> >>>> [email protected] >>> >>>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>>> >>> >>> >>> >>> _______________________________________________ >>> >>> caret-users mailing list >>> >>> [email protected] >>> >>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >> _______________________________________________ >>> >> caret-users mailing list >>> >> [email protected] >>> >> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> > >>> > >>> > _______________________________________________ >>> > caret-users mailing list >>> > [email protected] >>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: David Van Essen <[email protected]> >>> To: "Caret, SureFit, and SuMS software users" < >>> [email protected]> >>> Cc: >>> Date: Fri, 20 Jul 2012 20:25:22 -0500 >>> Subject: Re: [caret-users] Freesurfer Surface and Volume are not in >>> register when shown in Caret >>> Pablo, >>> >>> Registration to F99 should not be impacted by issues of scaling. (For >>> example, it doesn't affect our monkey-to-human registration despite large >>> scale differences.) But if you want to rescale just for the sake of >>> veridical representation, you can use >>> caret_command -surface-apply-transformation-matrix or Surface: Tranform: >>> Scale within Caret. >>> >>> David >>> >>> On Jul 20, 2012, at 6:27 PM, Pablo Polosecki wrote: >>> >>> > Hi Donna, >>> > >>> > Your excerpts were really inspiring. Many many thanks. I got them >>> > finally well-alligned. >>> > One more question: My volumes and surfaces have a nominal resolution >>> > of 1mm but they are actually .5mm (This means we scan at .5 mm >>> > resolution but we have to trick FreeSurfer into thinking we scan at >>> > 1mm because it doesn't display things correctly with other resolution >>> > values). Does this matter for working in Caret and registering to F99? >>> > Or do I have to rescale all my files back to .5mm? >>> > >>> > Thanks! >>> > Pablo >>> > >>> > On Fri, Jul 20, 2012 at 5:12 PM, Donna Dierker < >>> [email protected]> wrote: >>> >> Sorry I'm not as familiar with that script, but I am familiar with >>> scripts we use for importing human freesurfer files into Caret. Hopefully >>> these excerpts might help: >>> >> >>> >> #Find c_ras offset between FreeSurfer surface and volume and generate >>> matrix to transform surfaces >>> >> MatrixX=`$FreeSurferInstallationDirectory/bin/mri_info --cras >>> $InputFreesurferSubjectDirectory/mri/orig.mgz | cut -f1 -d' '` >>> >> MatrixY=`$FreeSurferInstallationDirectory/bin/mri_info --cras >>> $InputFreesurferSubjectDirectory/mri/orig.mgz | cut -f2 -d' '` >>> >> MatrixZ=`$FreeSurferInstallationDirectory/bin/mri_info --cras >>> $InputFreesurferSubjectDirectory/mri/orig.mgz | cut -f3 -d' '` >>> >> Matrix1=`echo "1 0 0 ""$MatrixX"` >>> >> Matrix2=`echo "0 1 0 ""$MatrixY"` >>> >> Matrix3=`echo "0 0 1 ""$MatrixZ"` >>> >> Matrix4=`echo "0 0 0 1"` >>> >> MatrixCRAS=`echo "$Matrix1"" ""$Matrix2"" ""$Matrix3"" ""$Matrix4"` >>> >> >>> >> for Surface in white pial ; do >>> >> caret_command -surface-apply-transformation-matrix >>> $OutputRootDir/$Subject/$InitialMeshDirectory/$Subject.$Hemisphere."$Surface"_orig.initial_mesh.coord.gii >>> >> >>> $OutputRootDir/$Subject/$InitialMeshDirectory/$Subject.$Hemisphere.initial_mesh.topo.gii >>> $OutputRootDir/$Subject/$InitialMeshDirectory/$Subject.$Hemisphere."$Surface"_orig.initial_mesh.coord.gii >>> -matrix $MatrixCRAS >>> >> done >>> >> >>> >> Also, it might matter which volume you use (e.g., orig.mgz vs others). >>> >> >>> >> >>> >> On Jul 20, 2012, at 3:55 PM, Pablo Polosecki wrote: >>> >> >>> >>> Hi Donna, >>> >>> >>> >>> I tried converting to RAS (this converst the heder information, which >>> >>> apparently Caret does use) and the data matrix. The problem is the >>> >>> same: the axes are correct (i.e., R points to the right side, D is >>> >>> dorsal, etc). However, the surface and the volume still don't match >>> in >>> >>> Caret just like before. The issue seems to be some sort of offset in >>> >>> the center of coordinates (when I click on the surface, the >>> >>> highlighted points seem to be on a sensible medio-lateral and >>> >>> dorso-ventral position. The problem is that the highlighted voxel is >>> >>> too posterior in the volume view). Does this make sense or hint to a >>> >>> possible solution to you perhaps? Worst case scenario, I could >>> eyeball >>> >>> how big this translation offset is, open the volume in matlab and >>> have >>> >>> it translate the data matrix. That way, it would roughly look okay, >>> >>> but perhaps there is a more graceful way of handling this. >>> >>> Thank you again, >>> >>> Pablo >>> >>> >>> >>> On Fri, Jul 20, 2012 at 3:14 PM, Donna Dierker < >>> [email protected]> wrote: >>> >>>> Be aware that what AFNI/Caret calls LPI, Freesurfer calls RAS. ;-) >>> >>>> >>> >>>> Can you try having mri_convert write the volume out as RAS, instead >>> of >>> >>>> LPI? Freesurfer will read the header and do the right >>> flipping/rotating >>> >>>> so that the surface aligns with it. Freesurfer did the right >>> thing, as it >>> >>>> understands that label. But that understanding is not what other >>> software >>> >>>> desires, in this case. (At least that's my read of your problem.) >>> >>>> >>> >>>> I think the axes don't need rotating anymore, but all three need >>> flipping. >>> >>>> >>> >>>>> Dear List, >>> >>>>> >>> >>>>> I successfully completed the FS-to-F99 tutorial and now I am >>> trying to >>> >>>>> reproduce the steps with my own FreeSurfer dataset. According to >>> the >>> >>>>> FS-to-F99 tutorial, I need to have my mri volume "into LPI >>> >>>>> orientation" and "the surfaces and volume need to be in register". >>> My >>> >>>>> original volume is in LIA orientation and is in register with my >>> >>>>> surface, in the sense that when I open both on FreeSurfer's tkmedit >>> >>>>> they are well-aligned to each other (I don't know how to check that >>> >>>>> they are in register otherwise). If I use this surface and volume >>> on >>> >>>>> FS-to-F99's Stage-1 script and open the resulting spec file with >>> >>>>> Caret, the volume's axes are wrong and the points on the surface >>> and >>> >>>>> in the volume don't match (I see this by clicking on the surface >>> and >>> >>>>> looking what is then highlighted on the volume window). If I >>> transform >>> >>>>> the volume into LPI orientation (using FreeSurfer's mri_convert >>> >>>>> command), the new volume has the desired orientation and, >>> >>>>> interestingly, it is still well-aligned to the surface in >>> FreeSurfer's >>> >>>>> tkmedit. However, when I use this surface and volume on the >>> FS-toF99's >>> >>>>> Stage-1 script, the volume and the surface are still not >>> well-aligned, >>> >>>>> even though the axes labels are now correct. How could I fix >>> things so >>> >>>>> that my volume and surface are in register when shown in Caret? >>> >>>>> >>> >>>>> Thank you very much, >>> >>>>> Pablo >>> >>>>> _______________________________________________ >>> >>>>> caret-users mailing list >>> >>>>> [email protected] >>> >>>>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> caret-users mailing list >>> >>>> [email protected] >>> >>>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>> _______________________________________________ >>> >>> caret-users mailing list >>> >>> [email protected] >>> >>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >> >>> >> >>> >> _______________________________________________ >>> >> caret-users mailing list >>> >> [email protected] >>> >> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> > _______________________________________________ >>> > caret-users mailing list >>> > [email protected] >>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>> >>> >>> >>> _______________________________________________ >>> caret-users mailing list >>> [email protected] >>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >>> >>> >> > _______________________________________________ > caret-users mailing list > [email protected] > http://brainvis.wustl.edu/mailman/listinfo/caret-users > > > > _______________________________________________ > caret-users mailing list > [email protected] > http://brainvis.wustl.edu/mailman/listinfo/caret-users > >
_______________________________________________ caret-users mailing list [email protected] http://brainvis.wustl.edu/mailman/listinfo/caret-users
