Glad things are moving in the right direction. Now it looks like maybe one
of the control points of the path is not moving around, which is why you
get that very bright thin spot in the distribution. I can't tell by
looking at that one slice of the mask only, but could it be that there
voxels missing from the mask around there? If so you could fill them in
and try again. You can also overlay the path.pd on the FA map and check if
that part is off the white matter or on its edge.
On Wed, 19 Oct 2011, Ping-Hong Yeh wrote:
The mask sort of covers the whole brain (see attached). It may be due
to the display thresholding, when I viewed the path.pd.nii.gz using
fslview, the tract actually has been recovered as compared to the
previous one (old_path.png).
However, the path.pd still does seem normal, i.e. with quite a few
extraordinary high intensity (probability, yellow)?
Thanks.
ping
On Wed, Oct 19, 2011 at 2:52 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - Do the corresponding brain masks in diffusion space
(dlabel/diff/aparc+aseg_mask.bbr.nii.gz and aparc+aseg_mask.flt.nii.gz) now
cover the entire brain well, after the aparc+aseg fixes?
a.y
On Tue, 18 Oct 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
I got fixed of the aparc+aseg (see aparc+aseg.png) in one of
problematic data and re-ran the trac-all following your suggestions.
However, the segmented forceps major using "FLIRT" still not getting
good result (see flt.png) though "BBR" one is OK (see bbr.png).
Similarly the segmented L CST using BBR looks weird, but the ones
using FLIRT seem OK.
It appear the problems are not simply due to the poor segmentation
from the T1 recon-all.
Any further suggestions?
BR,
Ping
On Fri, Oct 14, 2011 at 11:04 AM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping-Hong,
Yes, you can set usemaskanat = 0 in your dmrirc, and then the brain mask
will be extracted from the DWI data by the bet tool, instead of using the
aparc+aseg.
But, and this is a big but, TRACULA uses the aparc+aseg to constrain the
tractography solutions, i.e. the aparc+aseg is where the UnderLying
Anatomy
in TRACULA comes from. So the quality of the trac-all results depend on
the
quality of the aparc+aseg regardless of where your mask came from.
a.y
On Fri, 14 Oct 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
Can trac-all just use the mask in diffusion native space (by setting
"usemaskanat = 0"? ) so I get around the T1 segmentation problem from
FS recon?
It seems that there is no quick answer on fixing the aparc+aseg?
Thank you,
p
On Tue, Oct 11, 2011 at 10:35 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
I'll have to refer you back to the freesurfer list for that one. There
are
people with much more expertise than me on troubleshooting the
recon-all
stream.
Once you get your recons fixed, you'll have to rerun all trac-all steps
except 1.1 (image corrections).
On Tue, 11 Oct 2011, Ping-Hong Yeh wrote:
The original aparc+aseg are not good, at least for these two cases. So
which parameters in recon-all should be tweaked?
On Tue, Oct 11, 2011 at 5:38 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Is the original aparc+aseg from the freesurfer recon not good either
(from
mri/aparc+aseg.mgz)? Or is it messed up only after registration into
diffusion space (dlabel/diff/aparc+aseg.flt.nii.gz,
dlabel/diff/aparc+aseg.bbr.nii.gz)? This will determine if the
freesurfer
recon needs to be fixed or if the registration needs to fixed.
On Tue, 11 Oct 2011, Ping-Hong Yeh wrote:
yeap, the aparc+aseg_masks are not good.
Any way to fix this? Thanks.
On Tue, Oct 11, 2011 at 5:00 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
I see, the mask may be the answer to the initialization failures!
It
seems
like the fmajor you sent me also has its endings masked out? That'd
cause
it
to fail. I wish I'd thought of this earlier!
With usemaskanat = 1, the mask that's used is a slightly dilated
version
of
the aparc+aseg from the FS recon, mapped to diffusion space. So if
the
aparc+aseg has those parts missing, or if the diffusion-anatomical
registration is not good, parts will be masked out that shouldn't.
The
anatomical mask can be found in dlabel/diff/aparc+aseg_mask* (if
you've
run
both flirt and bbregister registrations, there'll be 2 of them).
Does
this
mask look like something went wrong?
On Tue, 11 Oct 2011, Ping-Hong Yeh wrote:
I used the default, i.e. set usemaskanat =1, but it looks that
tracts
were not reconstructed at the place where it was masked out (see
the
cross-bar at L_unc.png).
I still have no luck in fixing the initialization issue (see
fmajor.png for example).
Thanks.
On Tue, Oct 11, 2011 at 3:19 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - If you're using the anatomical brain as a mask (set
usemaskanat
=
1, which is the default), then the diffusion-based mask won't
have
an
effect
on your outputs.
BTW, have you had any luck with your initialization issues? Sorry
I
haven't
had another chance to look at your data since we last emailed, I
got
bogged
down with some other stuff.
a.y
On Tue, 11 Oct 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
I'd like to lower the bet threshold value by "set thrbet = 0.01"
for
skull-stripping because some of the brains have been cut, but it
does
not seem to make any changes (see attached).
Any suggestion? Thank you,
Ping
On Fri, Sep 30, 2011 at 12:09 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Yes! Please add the "set reinit = 1" to the file that you pass
with
-c.
On Fri, 30 Sep 2011, Ping-Hong Yeh wrote:
so I should pass with the -c argument instead?
On Fri, Sep 30, 2011 at 12:04 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
That file gets overwritten by whatever is in the file that
you
pass
with
the
-c argument to trac-all. Sorry for the confusion.
On Fri, 30 Sep 2011, Ping-Hong Yeh wrote:
I edited the file under scripts/dmrirc.local
On Fri, Sep 30, 2011 at 12:00 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - Thanks for trying that. When you say in the
dmrirc.local,
do
you
mean that you edit the file under scripts/dmrirc.local, or
the
file
that
you
pass to trac-all as "-c dmrirc"?
a.y
On Fri, 30 Sep 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
I've rerun NCNC0047, the one I sent you, and another one,
but
it
does
not help fixing the tracts.
I redone trac-all -prior with "set reinit =1" in the
dmrirc.local
file
and then trac-all -path
Any further suggestions? Thanks.
ping
On Thu, Sep 29, 2011 at 5:58 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
I wonder if the problem is with the replacement
executables
for
snow
leopard. They should not have a time stamp of April 14th,
I
don't
know
how
that could've happened.
Can you please try copying the version that I'm attaching
and
running
first
trac-all -prior and then trac-all -path with it?
If this version works, I'll have to reupload it and let
everyone
on
the
list
know. Thanks!
On Thu, 29 Sep 2011, Ping-Hong Yeh wrote:
The dmri_* files in the $freesurfer/bin are all after
May,
2011
(see
attached).
I think the one version, which failed on the MAC, has
been
replaced
by
the newer version. Is there a way to make sure the old
version
has
been deleted?
On Thu, Sep 29, 2011 at 4:28 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
The problem would be if the programs that trac-all runs
(dmri_*)
were
from a
version earlier than the stable 5.1 release, which was
made
public
in
late
May. Do you think you might have a different version on
this
machine
for
whatever reason?
On Thu, 29 Sep 2011, Ping-Hong Yeh wrote:
Thanks, Anastasia,
Most of the T1 segmentation results were done on
another
machine
using
V4.4.0, but the one running trac-all is on the machine
with
"freesurfer-i686-apple-darwin9.8.0-stable5-20110525".
Can
this
cause
the problem?
p
On Thu, Sep 29, 2011 at 1:43 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Thanks, Ping, I got the files. The Apr 14th build
time
stamp
is
suspicious,
since the official 5.1 release was a month later, and
these
initialization
issues were mostly what I was debugging during that
month.
When
was
your
version of freesurfer installed?
On Thu, 29 Sep 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
I followed the instruction on
http://surfer.nmr.mgh.harvard.edu/fswiki/FtpFileExchange
see if you can find the file there. Indeed I've
re-run
the
one
I
sent
you last night, now it seems OK for that particular
case.
I've loaded another one to the
https://www.nmr.mgh.harvard.edu/facility/filedrop/index.html
(still
loading while writing this email), which has severe
ventricular
dilatation and the result of right anterior thalamic
radiation
path
is
not right.
I've attached the picture of another case failed at
forceps
major
at
the first attempt, and the snapshot after manually
picking
the
initial
points. The gray scale intensity is still not right,
i.e.
the
initial
path is very high (yellow), the others are
significantly
low,
which
is
not I've usually seen. Does the gray scale still
represent
the
likelihood (probability) of path or something else
now?
Here is the output of dmri_train --all-info:
ProgramName: dmri_train ProgramArguments:
--all-info
ProgramVersion:
$Name: $ TimeStamp: 2011/09/29-16:41:32-GMT
BuildTimeStamp:
Apr
14
2011 15:35:19 CVS: User: twbrkmp2 Machine:
twbrkmp2s-Mac-Pro-5.local Platform: Darwin
PlatformVersion:
10.8.0
CompilerName: GCC CompilerVersion: 40200
Thank you,
Ping
On Thu, Sep 29, 2011 at 11:37 AM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - Did you try to attach it to your email? I
didn't
get
anything.
Please try our file drop site:
https://www.nmr.mgh.harvard.edu/facility/filedrop/index.html
a.y
On Wed, 28 Sep 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
I've loaded the file, pingforAY.tar.gz
This example data set failed in forceps major in
flt
and
L
slfp
in
bbr.
Thank you very much.
Ping
On Wed, Sep 28, 2011 at 6:17 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - You can upload your data if you want me
to
take
a
look
at
it.
1. The initial points ideally should be along the
midline
of
the
pathway,
starting from one end region of the pathway and
going
all
the
way
to
the
other end region. (The default number is 5
control
points
but
you
can
"set
ncpts = ..." in your dmrirc to change that.)
2. You can look in
$FREESURFER_HOME/bin/dmrirc.example
for
how
to
specify
the field map inputs. They don't need to have the
same
matrix
size
and
resolution as the DWIs.
3a. If it's the initialization that's failed, the
output
will
just
be
the
initial path and nothing else (which is I think
what
you
mean
by
"fewer
voxels").
3b. The diffusion model used here is the same as
the
ball-and-stick
model
that FSL uses. If the threshold you're referring
to
is
the
minimum
volume
fraction for the anisotropic compartments of that
model,
you
can
"set
fmin =
..." in your dmrirc to choose one.
I hope this helps a bit!
a.y
On Wed, 28 Sep 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
I've tried both options, the choice 1 fixed some
of
the
cases,
but
not all; and the choice 2 did not work at all.
Maybe
I've
missed
something here.
Few more questions:
1. Will the initial points have to include the
points
around
start,
way, and end points of the tracts need to be
segmented?
Can
I
just
enter the points in the main stem of tracts?
2. Will EPI distortion correction, like using
field
map,
in
the
preprocessing steps help co-registration and
thus
improving
the
labeling? So far more than 80% (4 out of 5 data
sets)
of
the
data
have at least one suboptimal tract, either in
flt
or
bbr.
(BTW,
which
flag will call B0 fieldmaps (or phase and
magnitude
images)
for
distortion correction? Do the fieldmap images
need
to
be
in
the
same
matrix size and resolution as DWI? )
3. I wonder why these suboptimal segmented
tracts
are
not
terribly
off the white matter paths but just fewer
voxels?
Would
the
probabilistic tractography implemented in FSL be
good
in
working
around this problem by lowering the threshold
for
tract
segmentation?
Thanks.
Ping
On Thu, Sep 22, 2011 at 1:18 PM, Anastasia
Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - There are 2 possibilities:
1. You can try to fiddle with the
initialization
points
yourself
to
make
sure they're well in the CST. The point
coordinates
are
saved
in
a
text
file
- look at the --init argument of the dmri_paths
command
line,
which
you
can
find in trac-all.log.
2. You can let trac-all select a different
initialization
by
adding
"set
reinit = 1" to your dmrirc file, then running
trac-all
-prior
again.
Once you change the initialization by doing
either
1.
or
2.
above,
you
need
to run trac-all -path to reconstruct this path
again.
You can change the pathlist in dmrirc to do
only
the
path
that
failed.
We jump through various hoops to make sure this
sort
of
thing
doesn't
happen
but in a few cases it can't be prevented,
unfortunately.
Let me know if this has helped or if you have
any
other
questions!
a.y
On Thu, 22 Sep 2011, Ping-Hong Yeh wrote:
Hi Anastasia,
The both ends were not terribly off of the
white
matter,
though
the
lower end was a bit off at the level of
decussation.
any
suggestion
in
fixing this?
Thanks.
ping
On Thu, Sep 22, 2011 at 12:51 PM, Anastasia
Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Ping - It looks like the path
initialization
may
have
failed.
The
algorithm needs an initial guess for the path
and
iterates
from
there.
This
initial guess is chosen based on the tracts
in
the
atlas
and
if
your
subject
is not perfectly aligned with the atlas this
initial
guess
might
end
up
going off the white matter for example. Does
the
blue
line
in
your
snapshot
look like it may not coincide well with you
subject's
CST,
going
off
the
white matter close to the end, etc?
a.y
On Thu, 22 Sep 2011, Ping-Hong Yeh wrote:
Hello,
The segmented left CST tracts of one of our
3T
data
was
not
satisfactory, which has only few voxels with
1000
gray
values
(see
attached snapshot pictures for "trac-all"
and
"cst_prob").
The
manually tracking using deterministic
tractography
seems
OK
(see
cst_stremline). Any suggestions on which
step
may
go
wrong
in
trac-all?
Thank you,
Ping
The information in this e-mail is intended
only
for
the
person
to
whom
it
is
addressed. If you believe this e-mail was
sent
to
you
in
error
and
the
e-mail
contains patient information, please contact
the
Partners
Compliance
HelpLine at
http://www.partners.org/complianceline . If
the
e-mail
was
sent
to
you
in
error
but does not contain patient information,
please
contact
the
sender
and
properly
dispose of the e-mail.
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
