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:
- 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)
- 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