[Freesurfer] Icosahedron nodes

[Emily Cooper]

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

[Freesurfer] (no subject)

[Lichen Liang]

Dear All,
I tried to extract a surface from a MRI scan (T1, 1.5T) using Freesurfer
3.0.3 on a Linux computer. I just run "recon-all" script for the same scan
6 times (same computer, no human interaction). To my supprise, I got 6
different results ( different #triangles, #vertices).  Go back to check the
intermediate results, all T1.mgz, WM.mgz are identical, but
lh.origdifferent. Can someone tell me why my results are not
consistent?
Thanks very much for your help.
Li-Chen
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Icosahedron nodes

[Doug Greve]

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
[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

Re: [Freesurfer] (no subject)

[Nick Schmansky]

Li-Chen,

Some of the utilities make use of random number generation in their
algorithms, specifically: mris_smooth, mris_sphere, mris_topo_fixer and
mris_ca_label.  While the number of vertices can change because of this,
the resulting stats (cortical thickness) should not differ by more than
0.5%.

If you need results to be perfectly consistent for a subject from run to
run, such as the case for our nightly testing scheme on a reference
subject, then you can add the -norandomness flag to recon-all, which
will seed the random number generator with the same number (instead of
seeding from the current time).

Nick


On Tue, 2006-12-05 at 12:16 -0600, Lichen Liang wrote:
> Dear All, 
> I tried to extract a surface from a MRI scan (T1, 1.5T) using
> Freesurfer 3.0.3 on a Linux computer. I just run "recon-all" script
> for the same scan  6 times (same computer, no human interaction). To
> my supprise, I got 6 different results ( different #triangles,
> #vertices).  Go back to check the intermediate results, all T1.mgz,
> WM.mgz are identical, but lh.orig different. Can someone tell me why
> my results are not consistent?
> Thanks very much for your help. 
> Li-Chen 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

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

Re: [Freesurfer] (no subject)

[Bruce Fischl]

Hi Li-Chen,

there is some intentional randomness in the algorithms. Try overlaying the 
surfaces and you'll see that they are visually identical I would think. 
Nick: is there a switch to recon-all to specify what the seed should be for 
the random # generators?


thanks,
Bruce


On Tue, 5 Dec 2006, Lichen Liang wrote:


Dear All,
I tried to extract a surface from a MRI scan (T1, 1.5T) using Freesurfer
3.0.3 on a Linux computer. I just run "recon-all" script for the same scan
6 times (same computer, no human interaction). To my supprise, I got 6
different results ( different #triangles, #vertices).  Go back to check the
intermediate results, all T1.mgz, WM.mgz are identical, but
lh.origdifferent. Can someone tell me why my results are not
consistent?
Thanks very much for your help.
Li-Chen


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

Re: [Freesurfer] (no subject)

[Nick Schmansky]

On Tue, 2006-12-05 at 13:31 -0500, Bruce Fischl wrote:
> Hi Li-Chen,
> 
> there is some intentional randomness in the algorithms. Try overlaying the 
> surfaces and you'll see that they are visually identical I would think. 
> Nick: is there a switch to recon-all to specify what the seed should be for 
> the random # generators?

The -norandomness flag can be added to recon-all.  It does not take a
number as input.  It will seed with the number '1234', which, by having
this number hard-coded in recon-all, means that you don't have to
remember what seed was used on some prior run.

Nick


> thanks,
> Bruce
> 
> 
> On Tue, 5 Dec 2006, Lichen Liang wrote:
> 
> > Dear All,
> > I tried to extract a surface from a MRI scan (T1, 1.5T) using Freesurfer
> > 3.0.3 on a Linux computer. I just run "recon-all" script for the same scan
> > 6 times (same computer, no human interaction). To my supprise, I got 6
> > different results ( different #triangles, #vertices).  Go back to check the
> > intermediate results, all T1.mgz, WM.mgz are identical, but
> > lh.origdifferent. Can someone tell me why my results are not
> > consistent?
> > Thanks very much for your help.
> > Li-Chen
> >
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 

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

Re: [Freesurfer] Icosahedron nodes

[Emily Cooper]

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 <[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). 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
[EMAIL PROTECTED]://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


--
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

Re: [Freesurfer] Icosahedron nodes

[Doug Greve]

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


In order to help us help you, please follow the steps in:

Re: [Freesurfer] Icosahedron nodes

[Emily Cooper]

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 <[EMAIL PROTECTED]> 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 < [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). 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
> [EMAIL PROTECTED]
> Phone Number: 617-

[Freesurfer] Running flame on mris_preproc output

[Luetcke, Henry]

Hi all,

I used mris_preproc to generate a surface file from 4 feat directories, as
described in the tutorial:

mris_preproc --out lh.cope1.nii.gz --target fsaverage --hemi lh \
--iv fbert1.feat/stats/cope1.nii.gz
fbert1.feat/reg/freesurfer/anat2exf.register.dat
--iv fbert2.feat/stats/cope1.nii.gz
fbert2.feat/reg/freesurfer/anat2exf.register.dat
--iv fbert3.feat/stats/cope1.nii.gz
fbert3.feat/reg/freesurfer/anat2exf.register.dat
--iv fbert4.feat/stats/cope1.nii.gz
fbert4.feat/reg/freesurfer/anat2exf.register.dat

I would now like to feed the resulting lh.cope1.nii.gz into fixed-effects
analysis with flame and tried the following:

flame -cope=lh.cope1.nii.gz -dm=design.mat -cs=design.grp -tc=design.con -fe

However, flame complains that not all compulsory arguments have been
provided. I guess I need a varcope file and a mask file. How can I generate
these, given that I am dealing with a surface format file?

Thanks very much in advance for your help.

Best regards,

Henry
 


Henry Lütcke
Biomedizinische NMR Forschungs GmbH
am Max-Planck Institut für Biophysikalische Chemie
 
Am Fassberg 11
37077 Göttingen
Germany
 
Phone:   +49-(0)551-201 1735
Mobile:  +49-(0)176-20808069
 
Mail: [EMAIL PROTECTED] 


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

Re: [Freesurfer] Icosahedron nodes

[Doug Greve]

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 <[EMAIL PROTECTED]> 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 < [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). 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
>
>