Chacko,
I'm not sure why it ran. Can you send a snapshot of the image not being
displayed correctly?
When I have seen partial displays in tksurfer in the past, the problem was
solved by updating the NVidia graphics driver (assuming the machine had
such a card), but if subject bert is displaying c
I think my fix topology sequence froze...I typed "top" in another
terminal and this is what came up...
ID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
899 surf 25 0 2169m 1.6g 1984 R 99.1 43.1 1042:33 mris_fix_topolo
18609 root 15 0 457m 196m 8616 S 0.7 5.3
You must have a number of *huge* defects:
163949 ambiguous faces found in tessellation
segmenting defects...
93 defects found, arbitrating ambiguous regions...
usually the # of defective vertices is less than 1/10 of this. Try loading
the ?h.defect_labels (with tksurfer->file->load curv) onto
Well, I figured out what my problem is. The skull strip only took off
about a quarter of the skull on the top. Any suggestions on how to
correct this?
Quoting Bruce Fischl <[EMAIL PROTECTED]>:
> You must have a number of *huge* defects:
>
> > 163949 ambiguous faces found in tessellation
> > se
look at:
https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial_2fSkullStripFix?action=highlight&value=skull+stripping
On
Fri, 23 Jun 2006 [EMAIL PROTECTED] wrote:
Well, I figured out what my problem is. The skull strip only took off
about a quarter of the skull on the top. Any suggestions o
Dear All,
Is the total white matter volume computed by mris_anatomical_stats
the total volume inside the gray/white surface? Or does it exclude
subcortical structures? i.e. is total brain volume = total gray matter
volume + total white matter volume ?
Thanks,
Sasha
Sasha Wolosin
Research Ass
it's the volume of the wm.mgz, and it's deprecated. Use the various wm
volumes in the aseg files (or aseg.stats) instead.
cheers,
Bruce
On Fri, 23 Jun 2006, Sasha
Wolosin wrote:
Dear All,
Is the total white matter volume computed by mris_anatomical_stats
the total volume inside the gray/wh
Hello All,
So I tried using recon-all to get a few parcellations stats from a minc
file it but I'm getting the following error. Please could someone say
how this can be rectified. Thanks. - Anil Roy.
This is the command I'm giving:
# recon-all -force -i /root/Desktop/F100.mnc -subjid F100 -sd /u
is there a way to compute the volumes contained within the ?h.pial and
?h.white surfaces?
>>> Bruce Fischl <[EMAIL PROTECTED]> 6/23/2006 4:41 pm >>>
it's the volume of the wm.mgz, and it's deprecated. Use the various wm
volumes in the aseg files (or aseg.stats) instead.
cheers,
Bruce
On Fri, 23
mris_anatomical_stats will give you the volume of the ribbon. There's also
a program Xiao Han wrote called mris_volume that will compute the interior
volume of any closed surface. Not sure if it's in your distribution, but
it's in dev (and stable3 I think)
Bruce
On Fri, 23 Jun 2006, Sasha Wo
what steps have you run previously? You don't need to specify -i on later
stages, just the subjid and sd.
On Fri, 23 Jun 2006, Anil Roy wrote:
Hello All,
So I tried using recon-all to get a few parcellations stats from a minc file
it but I'm getting the following error. Please could someone s
Title: Message
Hi
folks,
I want to use
mri_convert to convert 30 direction diffusion data
to NIfTI-1 format. I
ran it and it seemed to work good. I just wanted
to clarify one
thing. The docs seem to say that unless I use --conform
it will not
interpolate my data to 1mm res, or change it in
Hi Greg,
yes, you definitely don't want to interpolate the diffusion data to 1mm
Bruce
On
Fri, 23 Jun 2006, Kirk, Gregory wrote:
Hi folks,
I want to use mri_convert to convert 30 direction diffusion data
to NIfTI-1 format. I ran it and it seemed to work good. I just wanted
to clarify one thi
This is the first step. I assumed that recon-all should do all the processing by itself without the need to run anything previously. Please mention if any extra steps have to be taken before the parcellation stats (or the entire recon-all process) can be obtained from the minc file.
Thanks - Anil.O
well, you specified -autorecon3, which assumes some stuff has been run
before. If you want to do everything from beginning to end run -all instead
Bruce
On Fri, 23 Jun 2006, Anil Roy wrote:
This is the first step. I assumed that recon-all should do all the
processing by itself without the nee
Probably Nick or Bruce:
Could you confirm what I think I remember: that in the algorithm to move
the surface out from the white position to the pial, FS is constrained by a
5 mm limit?
-- Is this documented somewhere, with other details like what unwanted
behavior this prevented, in what reg
Hi Graham,
actually the limit is in the thickness measurement, not the deformation.
You can recreate the thickness files with mris_thickness -max $maxthick ...
if you want a larger value. What's going wrong?
Bruce
On Fri, 23 Jun 2006, Graham Wideman wrote:
Probably Nick or Bruce:
Could yo
Bruce:
Thanks for your reply --
actually the limit is in the thickness measurement, not the deformation.
You can recreate the thickness files with mris_thickness -max $maxthick ...
if you want a larger value. What's going wrong?
Well we're trying to guess why the pial surface is somewhat co
probably not. Check the intensity of the white matter underlying the gray
and see if it's significantly less than 110. If so, try putting a few
control points there (make sure they aren't in partial-volumed wm)
Bruce
On Fri,
23 Jun 2006, Graham Wideman wrote:
Bruce:
Thanks for your reply -
At 6/23/2006 06:57 PM, you wrote:
probably not. Check the intensity of the white matter underlying the gray
and see if it's significantly less than 110. If so, try putting a few
control points there (make sure they aren't in partial-volumed wm)
Bruce:
You would recommend this, even though the
if you put them in the body of the wm (where the intensity in the T1.mgz
vol is < 110), it shouldn't effect the placement of the boundary
substantially
On Fri, 23 Jun 2006, Graham Wideman wrote:
At 6/23/2006 06:57 PM, you wrote:
probably not. Check the intensity of the white matter underlying
21 matches
Mail list logo