Thanks for responce, Dough.
I've looked at recon-all as you suggested, and came up with the following
commandline:
mris_anatomical_stats -mgz -f
lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/lgi.annot.ctab
$SUBJECT lh pial_lgi
This, however yields segfault:
INFO: assuming MGZ format
Martin,
Try instead the option -t pial_lgi as follows:
mris_anatomical_stats -mgz -f
lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/
lgi.annot.ctab -t pial_lgi
$SUBJECT lh
Otherwise it will read lh.pial_lgi as a surface file, whereas it is
indeed a thickness / curv file
Have a
Thanks a lot help, Marie.
Indeed the -t switch worked.
Now, the lh.aparc.stats (thickness) and my generated lh.lgi.stats (lGI) differ
in the columns 4,5,6, which correspond to GrayVol, AverageThk, and StdevThk.
Could you please help me to understand these values?
1. Why is the GM volume diffe
Martin,
As lgi is read like a thickness file, the lgi values in your tabular
output replaced the value where you had thickness before. So mean lgi
is in column 4 (note that average lgi values per parcell are
comprised between 1 and 5 if your lgi computation is ok). Standard
deviation for
Thanks a lot for clarification, Marie.
On Friday 09 May 2008 14:37:46 Marie Schaer wrote:
> Martin,
>
> As lgi is read like a thickness file, the lgi values in your tabular
> output replaced the value where you had thickness before. So mean lgi
> is in column 4 (note that average lgi values per pa
On my understanding, the GM volume given by mris_anatomical_stats
should be the same independently of the -t option (unless you
reprocessed the surfaces in between), so that's surprising.
Doug, do you have any idea?
Marie
On 9 mai 08, at 15:12, Martin Kavec wrote:
Thanks a lot for clar
Just a thought, but I suspect that the volume is calculated as some
product of area * "thickness". Then, with the -t option, what FS is
using as thickness is now really the lgi value. So, the "volume" value
is really not appropriate in that case.
cheers,
Mike H.
On Fri, 2008-05-09 at 15:28 +
Hi Pradeep,
it's impossible to tell if it's an error from a single slice. Things that
look like holes may actually just be sulci if you page through a couple
of slices. You should also be looking at the intensity volume (e.g.
norm.mgz) not just the wm.mgz. If the surface follows the gray/white
Hello,
I am getting an error saying that the path from the findsession command is
not found. Here is the bugr information and following is the log from my
terminal window; could anyone explain why the directory from findsession
is missing? THANKS!
FREESURFER_HOME: /usr/local/freesurfer/stable4
Questions on infrastructure issues at the Martinos Center like disk volumes
you should direct to the Martinos IT support group at
[EMAIL PROTECTED]
I see no problem on striatum right now. It can see
/space/archive/160/siemens/TrioTim-35162-20080503-192630-556000
just fine.
Looks like you r
Hello all,
I am new to Optseq2 and I have a question about generating 2-way design
orders using the program and about a question about temporal jitter. I am
working on a design with 7 conditions. I have run the following design
through optseq2 and gotten out reasonable looking orders.
--ntp 160
Hi,
I have tried applying a binary mask, specifically for STG, in conjunction
with the mri_mask command. We applied it to a brainmask volume, but we did
not get the result we wanted. The output we recieved was simply the mask
that we used. We wish to produce an output that gives the STG volume alo
Please note the command we used:
mri_mask brainmask.mgz lh.stg.mask.mgz brainout.mgz
and the result we got was:
Writing masked volume to brainout.mgz...done.
On Fri, May 9, 2008 at 2:39 PM, Daniel H Choi <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I have tried applying a binary mask, specifically for
13 matches
Mail list logo
