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 < greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu> 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 greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu 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

hi emily,

let's back up a minute. Try running mri_vol2surf using fsaverage as the target (this is basically the same as ico7). Then when running mris_convert, specify the ?h.white in the fsaverage/surf dir.

doug

On Tue, 5 Dec 2006, Emily Cooper wrote:

hi doug,

the target subject of mri_vol2surf was ico7 when i got the error in mris_convert. i tried using the command you gave when the target was the individuals sphere.reg, and got a text file with 5 columns. is the last column the intensity values? is there a way to use this command on data mapped onto ico7?

emily

On 12/5/06, Doug Greve greve@nmr.mgh.harvard.edu wrote:

...

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.whitetrim_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 < greve@nmr.mgh.harvard.edu> 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). 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 https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu 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

...

-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu 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