Hi Octavian --
On Wed Oct 3 17:43:51 2012, octavian lie wrote:
mris_pmake --subject A --hemi rh --surface0 sphere.reg --curv0 sulc --curv1 sulc --mpmOverlay euclidean --mpmProg pathFind --mpmArgs startVertex:1,endVertex:2
That seems about right if you want to use the spherical surface.
Questions:
- Is the calculated path the geodesic, in this case
spherical, measure that can be directly compared with that from another subject, or not?
The paths are calculated on the *actual* mesh surface. So, if you're using a spherical surface (as opposed to say, the 'smoothwm') you're getting close to a geodesic but it is not a true geodesic. Still, they should be quite usable for your purposes.
- How could I compare the distance on the pial surface of subject 1
(vertex 1-vertex 2) to subject 2 (vertex 1 to2). Is changing --surface0 argument to pial enough?
Yes, that should work for computing distances on another surface.
(In the Recon-all Dev table,
sphere.reg is an imput to generating label/?h.aparc.annot, which in turn is used to generate ?h.pial surfaces, does that mean that pial surfaces from 2 subjects are already registered?)
I'm not sure about your logic here. Keep in mind that by registering two subjects together you by necessity distort one of them. You should probably take care to compute distances on the original surfaces, not the registered ones or spherical ones. Plus, I'm not sure that registering two surface together allows for such one-to-one vertex index translations.
You would probably be better off visually/manually defining analogous regions/vertices on the two surfaces and computing the distances between those.
- I do not understand the choice of defaults for --surface0
(inflated) , --surface1 (smoothwm), curve 0 and 1.
This is a historical artifact of earlier use cases for 'mris_pmake'. Sorry... FWIW the current development version of 'mris_pmake' does away with '--surface0' and '--surface1' (just using '--surface') and the '--curv' flags are depreciated.
Do I need to change any of the auxilliary terms used above with sphere.reg to accomplish what I want to accomplish?
No, in your case you should only care about 'surface0'. The 'surface1', 'curv0', and 'curv1' terms are not relevant to the pathFind/euclidean use, and are really just dead appendices.
- Last, is there a way to mark the vertices for these geodesic path
on the main surface used in order to use then for label creation?
Yes. Look in the 'options.txt' file and make sure that the 'b_labelFileSave' flag is set to '1'. The name of the output file can be set with the 'labelFile' setting.
Your insight is very important, thank you, Octavian.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Rudolph Pienaar, M.Eng, D.Eng / email: rudolph@nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street, Charlestown, MA 02129 USA