I've rigged the curv format reader to recognize volume files used to encode surface values, so anything that accepts curv will also accept mgh. The issue on the number of vertices is whether the rh.white is that of the target subject used with mri_vol2surf. Are you using fsaverage?

doug



Emily Cooper wrote:

Hi Doug,

I tried commands like this one initially, originally getting a "Segmentation fault" error. It was my understanding from the help file that using the -c flag specified that I want to convert the curv file to .asc. What I would like to do is convert a functional file to .asc. A command like

mris_convert trim_action.100.int.surf.pfa10.forconvert.mgh trim_action.100.int.lh.white.asc

inputing either an mgh in the subjects space or mapped to icosahedron space gives that same error, which is why I switched to using .w as input. However, including the -c flag gives a different error:

mris_convert -c trim_action.100.intval.ico7.mgh rh.white trim_action.100.int.rh.white.asc
INFO: NOT fixing vertex area
ERROR: number of vertices in trim_action.100.intval.ico7.mgh does not match surface (163842,156835)

maybe because functional data in the icosahedron space does not have at .white file?

Emily

On 12/5/06, Doug Greve < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Hi Emily,

    don't use .w files as they might generate a different number of
    data points. The number of nodes is constant, but the .w file will
    attempt to do a "compression" by eliminating nodes that are 0.
    This, of course, turns into a bookkeeping mess, which is why I
    discourage the use of .w files. Use mgh instead. You should then
    be able to use mris_convert to convert to ascii, something like:

    mris_convert -c your.mgh lh.white your.asc

    doug




    Emily Cooper wrote:

    Dear FreeSurfer gurus,

    We are trying to conduct a simple group analysis, employing
    freesurfer. However, our aim is to use the software only up to the
    point where the functional data is projected to a common space, and
    from that point on export the data to a text file and conduct the
    analysis using an external mathematical package (R,
    http://www.r-project.org <http://www.r-project.org/>). We have
    received very useful information
    from this message board in the last 2 weeks assisting us in this
    endeavor, but are still stumped by part of the workflow.

    At this point, we have succeeded in projecting our functional files
    (AFNI format) to the FreeSurfer surface representation so that each
    individual functional data is project to the individual registered
    surface. Given that each individual surface has a different
    number of surface
    nodes, we reasoned that to conduct a group analysis, it would be
    necessary to project the functional data not to the individual
    surface
    of each participant, but instead, to the registered icosahedron
    representation. The documentation of mri_vol2surf states that
    using the "icoorder" option, will result in mapping to an
    icosahedron
    with *prespecified* sizes. Specifically, we have tried projecting to
    an ico with order 7 (documentation states 163842 nodes in this
    reprsentation).
    However, when using this option and
    outputting to a "paint" (.w) file, we do not get this number of
    nodes
    for the icosahedron. Instead, different subjects' icosahedrons have
    different numbers of nodes. This is evident when the paint file is
    converted to and ".asc" file via mris_convert. Before we
    continue, we
    would like to know if this is a bug in mri_vol2surf, in mris_convert,
    or perhaps not a bug at all (i.e., different icosahedrons may indeed
    have different number of nodes by design).

    Now that we find ourselves with no way to equate the number
    of nodes in each participants' surface representation we are faced
    with a quandary: How do we conduct the group analysis?  It has been
    suggested to us that we use the surf2surf utility. The documentation
    of that utility mentions that both the src and target surfaces
    may be
    icosahedrons.  If we do indeed need to use this utility, should
    we map
    data between icosahedrons, or would it be better to cut down one
    stage
    of interpolation and just directly project the surfaces of all
    subjects to one reference subject ( e.g., subject b -> subject a,
    subject c ->subject a, and so on).

    Thanks for any assistance,
    Emily

------------------------------------------------------------------------

_______________________________________________
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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Phone Number: 617-724-2358 Fax: 617-726-7422

In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting 
<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting>



--
Douglas N. Greve, Ph.D.
MGH-NMR Center
[EMAIL PROTECTED]
Phone Number: 617-724-2358 Fax: 617-726-7422

In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting


_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Reply via email to