I don’t see any errors in the attached log.
I noticed that you specified ‘-parallel’ in your recon-all. It is the
parallelism done at recon-all level. There is no synchronization mechanism to
guard shared sources accessing. There have been reports of ‘ln -s’ errors due
to that. I’m wondering if
check the talairach.xfm transform and see if it is accurate.
cheers
Bruce
On Tue, 12 Jan
2010, Xiantong Zhen wrote:
Hi experts,
I run freesurfer to compute the thickness, but I find some subjects failed with
error.
Would you please tell me how to handle this error. Thank you very much!
And
Thanks again!
I'm working on some other analyses right now, but I will report back once i
get a chance to run this again...!
- Jerry
On Tue, Apr 29, 2008 at 11:52 AM, Bruce Fischl <[EMAIL PROTECTED]>
wrote:
> 1. It should be very sensitive to this - just make sure the white matter
> is at least 1
1. It should be very sensitive to this - just make sure the white
matter is at least 100 or so in the image (it can be more).
2. You shouldn't need to erase anything - just rerun recon-all
cheers,
Bruce
On Tue, 29
Apr
2008, Jerry Yeou-Wei Chen wrote:
Okay, thanks! I'll give that a shot...
Okay, thanks! I'll give that a shot... but I have a couple of questions
beforehand:
1) How would you recommend that I decide what scale factor to use? Trial and
error to get a peak of ~116?
2) Should I run cp and mri_convert, then erase all other existing files and
folders, and rerun recon-all from
Hi Jerry,
I think you can do something like:
cp 001.mgz 001_orig.mgz
mri_convert --scale 3 001_orig.mgz 001.mgz
then the same for the other runs and see how that works in recon-all.
Usually we detect and account for this, but I guess something is failing in
your case.
cheers,
Bruce
On
Mo
Hi Bruce,
Looking at one of the successfully processed subjects in tkmedit, I would
guesstimate the range in the brain to be ~20-65. The corresponding 001.mgz
is equally dark.
Regarding the scale option, would I run that initially ( with --scale ), and then run autorecon as normal?
Do I find the
p.s. are the 001.mgz and 002.mgz dark? The orig.mgz? Sometimes nu_correct
can create very dark images, and there are some switches you can loo
through to correct them. Alternatively if it is the 001.mgz, mri_convert
has a scale option you can use.
cheers,
Bruce
On Fri, 25 Apr 2008, Jerry Yeo
it can be trouble if they are that low, as you lose dynamic range in the
8-bit representation. What are the ranges in orig.mgz?
On Tue, 22 Apr 2008,
Nick Schmansky wrote:
Jerry,
At this point, I think Bruce will need to jump-in to answer (he is out-
of-town today). I think he will ask about
Okay, thanks for your help again Nick!
Regarding the scan data: I am actually working with data collected by a
previous member of our lab, and there were indeed some problems... (related
to the SCIC algorithm on our GE scanner). So, our technician created a
program to "uncorrect" the intensity scal
Jerry,
At this point, I think Bruce will need to jump-in to answer (he is out-
of-town today). I think he will ask about your scan parameters, ie, how
is your scanner setup? It sounds as if something is not quite right in
the data coming-off the scanner.
Nick
On Tue, 2008-04-22 at 14:26 -0400
Thanks for the reply, Nick. I think you correctly identified the problem.
nu.mgz is oriented correctly, but looks very dark... However, it looks
decent if I adjust the brightness/contrast
I have other scans that were processed without error, and the orig.mgz, and
nu.mgz also appear quite dark (
Jerry,
I'm not sure why it exited without giving a better message, but this is
a clue why it exited:
before smoothing, mri peak at 0
after smoothing, mri peak at 0, scaling input intensities by inf
the mri peak is at zero, which is wrong (it should be around 116/117 or
so).
if you view nu.m
13 matches
Mail list logo
