For some reason, my DWI output from DTIPrep is flipped posterior-to-anterior (see attached image). I have confirmed that none of the raw data, including T1, have this same flip. My code is below and uses AFNI, DTIPrep (1.2.9), and DWIConvert from Slicer (4.6.2)
------------------



-------------------
Do you know what might be causing this problem? I did not have this same issue in DTIPrep 1.2.4 as far as I remember.

Thanks,
Steven

In the meantime, incase anyone else has this problem, here is a workaround that uses FSL. [url=https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/Orientation%20Explained]It isn't the most elegant solution[/url]:

fslorient -deleteorient dwi_QCed.nii.gz
fslswapdim dwi_QCed.nii.gz -x y z dwi_reorient.nii.gz #WHETHER X Y AND Z ARE POSITIVE OR NEGATIVE DEPENDS ON THE ORIENTATION OF YOUR BRAIN
fslorient -setqformcode 1 dwi_reorient.nii.gz

Hi Steven

This may be an imperfect conversion to/from NIFTI. 
Best way to check is to use 3D Slicer and load the NRRD file after DWIConvert, as well as after DTIPrep. If they are both flipped then it's the conversion (or a data issue prior to conversion to NRRD). If neither is flipped, then it may be the conversion back to NIFTI (or a header interpretation issue after the conversion within FSL).

There can be issues of coordinate spaces in NIFTI when processing data with FSL. The processing in FSL can change the coordinate space information, sometimes only partially, in the NIFTI header even when no registration is performed. This is not a problem when you stay within FSL, but can be an issue if you use the NIFTI files in other tools.

Quick question: how did you do the conversion from DICOM? The way we do it in the lab (and we alternate between NIFTI and NRRD quite a bit and usually it's an issue on NIFTI/FSL's side) is that we start with converting DICOM to NRRD using DWIConvert. Then run DTIPrep and finally convert to NIFTI for processing in FSL. DWIConvert is also used by the 3D Slicer groups for surgical planning (so I do trust its DICOM conversion quite a bit).

Martin

Hi Martin,

Thanks for the quick reply. Turns out the problem was in DWIConvert, albeit I do not know where. Our lab typically will do DCM --Dcm2Nii--> Nifti --DWIConvert---> NRRD --DWIConvert--> Nifti, since not everyone uses DTIPrep (yet....) and most people are using FSL or similar apps. I do not know why it is only happening with this particular dataset, as far as I know.

We use dcm2nii for our fMRI data (dcm2nii is a very nice tool), but have made the experience that DWIConvert provides better conversion from DICOM (rarely needs manual correction), particular for Siemens data. We commonly use the Bmatrix option of DWIConvert that computes the actually applied b-val and b-vec rather than those recorded in the DICOM tags (which commonly are the prescribed values and not the actually applied ones, though in truth the difference is minimal).

If your folks prefer NITFI then they could also use DWIConvert --conversionMode DicomToFSL

Martin

Do you know what version of Slicer the DWIConvert on the Downloads page is from? I think Slicer 4.10 introduced a new DWIConvert that fixes this issue, looking at the Slicer forum. I unfortunately am having trouble installing new full builds on my HPC.

Originally posted by Steven Meisler:
I quickly checked with the version installed on my Mac Slicer 4.10.2. If I run:
/Applications/Slicer4.10.2.app/Contents/lib/Slicer-4.10/cli-modules/DWIConvert --version

then I get:
/Applications/Slicer4.10.2.app/Contents/lib/Slicer-4.10/cli-modules/DWIConvert version: 4.8.0

Thus the one that I recently uploaded (version 4.6, compiled independently from Slicer) is a bit older than the one in Slicer 4.10. 

Quick question on your cluster computation issues: Is it an installation issue or are rather how to call DWIConvert from the command line/in a script?

On the UNC HPC, this works for me (Slicer installed in our lab disk space that is shared with the compute nodes):

/proj/NIRAL/tools/Slicer-4.10.2-linux-amd64/Slicer --launch DWIConvert --version

/proj/NIRAL/tools/Slicer-4.10.2-linux-amd64/bin/../lib/Slicer-4.10/cli-modules/./DWIConvert version: 4.8.0

Best
Martin

Just tried out DWIConvert 5.2 from Slicer 4.11, it fixed the problem!

Originally posted by Steven Meisler: Perfect!

If you could somehow upload a standalone version of the DWIConvert from Slicer 4.10 or above that would be appreciated. Since slicer looks for shared library files I have to do some tinkering for Slicer to go to my Slicer installation instead of the central Slicer installation; it has not been consistently working. Maybe I can get admin to update the central install too.

Originally posted by Steven Meisler: I just uploaded a near standalone version of DWIConvert 5.3.0 (it has one non-standard dynamic library association, libtbb, which is in the same zip file) to the Download section. Hope this works for you.

Best
Martin

Hi Martin, 

We are having the same issue discussed above (both the flipping of images and shared library issues when running Slicer). The available standalone version (DWIConvert 5.3.0) is asking for a very old version of the Unicode library (libicuuc version 50) that we do not have on our servers. Would it be possible to have a standalone download for the DWIConvert from Slicer 4.11 or 4.13?

Thanks for your help!

Beth

Hi Beth

I just uploaded a static compilation of DWIConvert 5.3.0 (current version, freshly compiled from the BRAINTools repository). This is still compiled on CentOS/RH 6 (that's the system we have in the lab), but no longer needs libicuuc. Hope this helps.

Go to the download section for this version. 

Hope this helps
Martin
Originally posted by Beth Kruse:

Great, thank you Martin!