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:
1. 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.
2. 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.
3. 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.
4. 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: rudo...@nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street, Charlestown, MA 02129 USA
___
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.
