Hi Satra - There are 2 ways to put things "in proper orientation for fsl
tools":
1. L-R flip the gradient vectors: This is a hack, in the sense that it
anticipates that FSL will treat your volume as L-R flipped when it has a
certain type of orientation, but now you've broken your bvecs for the
purposes of any software that doesn't do that (like freesurfer).
2. Convert both the volume and the gradient vectors to LAS orientation:
This is not a hack, in the sense that now you have volumes and vectors
that work both for FSL and otherwise, and work regardless of the original
orientation.
Obviously, you want to do 1 OR 2, not both. What's breaking things for
you is that your preprocessing is doing 1 and then trac-all preprocessing
does 2.
I've opted for 2 in trac-all b/c I need the files to work for both FSL i/o
routines (in bedpostx, most critically) and for freesurfer i/o routines
(in my own code for tracula). Alternatively, I could keep two sets of
everything and feed one set into the FSL routines and the other into the
freesurfer routines, but this would be inelegant, a pain to implement, a
recipe for introducing bugs, and, unltimately, a sure way to wipe out
whatever little is left of my sanity.
Any other aspect of default preprocessing in trac-all (eddy currents,
susceptibility) can be turned off if you want to use another method to do
it. But it's not possible to turn off this way of making things compatible
with FSL to use that way of making things compatible with FSL. If you want
to try it, you can replace every instance of flip4fsl with cp and let me
know what happens, I'd be really curious.
Hope this helps,
a.y
On Tue, 2 Jul 2013, Satrajit Ghosh wrote:
hi ay,
so this is what i did. i flipped the gradient LR intentionally, ran flip4fsl
and then dtifit and now the eigenvec 1 looks good, but not if i run dtifit
prior to flip4fsl.
but this brings me back to my original point which is that my image and the
gradients are (i think) already in proper orientation for fsl tools (since
the preflip output in the previous email looks correct) and flip4fsl is
making it inappropriate for fsl.
also as some additional info:
- yes this is the siemens 60 dir scan but that predefined gradient table
doesn't take into account the slice orientation
- if you use dcm2nii to extract these dicoms, the first two gradients are:
0.996362388134 0.0389195755124 -0.07581084221601
-0.65292024612426 0.00993375014513 -0.75736147165298
this is because dcm2nii, much like DTIPrep takes the image orientation
matrix into account when doing the conversion, which mri_convert doesn't.
so i think tracula should have an option of not flipping 4 fsl in the
scenario where other processes (e.g., my script, dcm2nii) automatically take
care of generating an fsl compatible file + gradient info.
please let me know if i'm misinterpreting something here.
cheers,
satra
On Tue, Jul 2, 2013 at 8:21 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Satra - What you're showing in the screenshots would be
consistent with a L-R flip of the gradient directions, which is
what my comparison of your gradients to the original Siemens
gradients indicated. (Assuming the data was acquired with the
standard Siemens 60 gradient directions.)
a.y
On Tue, 2 Jul 2013, Satrajit Ghosh wrote:
hi ay,
i'll look into the orientations a little later
tonight, but here is V1
overlaid on FA for preflip and postflip execution of
dtifit.
cheers,
satra
On Tue, Jul 2, 2013 at 7:48 PM, Anastasia Yendiki
<ayend...@nmr.mgh.harvard.edu> wrote:
Hi Satra - The orientation of your
dwi_orig.nii.gz is LPS. What
flip4fsl will do is convert it to LAS, and
perform the same
conversion on the gradient table that you
provide. This of
course assumes that dwi_orig.nii.gz and your
gradient table are
consistent as they come out of your custom
preprocessing. Is
there any chance that they're not?
Looking at the sample data set that you sent
me, I can only see
what came out of your preprocessing and not
what went in. I'm
assuming that this is from the standard
Siemens 60 direction
sequence, and it has 57 directions b/c 3 of
them were thrown out
by your preprocessing. I don't know which
directions were thrown
out obviously, but the first 2 directions in
your gradient table
are:
-0.99699027939850948 -0.057720153020443053
0.051758263409041924
0.63287878858184599 0.066164234845749903
0.77141869630019422
The first two directions in the Siemens 60
direction gradient
table are:
1.0000000000 0.0000000000 0.0000000000
0.5867917880 -0.3765825401 -0.7168409782
There's not only a small adjustment of the
direction but also a
sign change there. So I'd look into that.
Let me know if any of my assumptions about
your original data is
wrong.
a.y
On Tue, 2 Jul 2013, Satrajit Ghosh wrote:
hi anastasia,
i'm trying to debug a seg fault that
some folks are
seeing deep into a
tracula run.
process:
1. feed dicoms to a script that runs
DTIPrep and
outputs a nifti file, bvec,
bval
(among checking for many artifacts, this
reduces the
b=0 volumes to a single
registered mean volume, runs eddy
correction,
discards bad directions,
reorients the gradients appropriately
and generates
a report of the quality)
2. run tracula on this nifti file
observation:
when i run fsl/dtifit on the same nifti
file + bvec
+ bval, i get the proper
orientation for eigvec1 lines. however,
when i feed
this into tracula, the
output of the dtifit step looks terrible
- i.e. the
lines are not oriented
as how one might expect water to
diffuse.
suspicion:
although i have not reached the crash
yet, i believe
it might be related to
this fact that the gradients are not
oriented
properly relative to the
volume.
i also suspect that this has something
to do with
the flip4fsl step inside
tracula, which is possibly unnecessary
because fsl
already likes the input
files. but it seems this step is encoded
quite
heavily within the trac-all
scripts.
questions:
a. is there a quick way to turn the
flip4fsl step
off?
b. alternatively do you have any
suggestions for
what to do here?
the whole point of running through
DTIPrep is to
clean up the data before
giving it to tracula or other programs,
so i would
really like to keep that
step.
cheers,
satra
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.
