Re: [Freesurfer] [tracula] running into trouble with nifti data
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
Re: [Freesurfer] [tracula] running into trouble with nifti data
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.00 0.00 0.00 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 ___ 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.
Re: [Freesurfer] [tracula] running into trouble with nifti data
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.00 0.00 0.00 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
Re: [Freesurfer] [tracula] running into trouble with nifti data
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.00 0.00 0.00 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
