Hi, on a volunteer scan, GE 3T, 29.1 R02, we acquired 70 direction DTI over two different frequency encoding directions, L/R vs. A/P. I converted both directionally encoded color (“dec”) images using these commands:
The A/P (right volume) encoding appears reversed compared to the correctly calculated L/R (left volume) dec, see below. It appears that S/I is correct, but L/R and A/P are flipped? Images are displayed using ITKSnap v3.8.
The results of mrinfo -property dw_scheme and mrinfo -dwgrad are identical for both series using the master branch.
# no output, meaning the gradients are the same as recorded in the DICOM
diff <(mrinfo -quiet -property dw_scheme MR-INNOVATION-20221014/Ax-DTI-70-dir-default-Freq-A-P-2/) <(mrinfo -quiet -property dw_scheme MR-INNOVATION-20221014/Ax-DTI-70-dir-default-Freq-R-L-5/)
diff <(mrinfo -quiet -dwgrad MR-INNOVATION-20221014/Ax-DTI-70-dir-default-Freq-A-P-2/) <(mrinfo -quiet -dwgrad MR-INNOVATION-20221014/Ax-DTI-70-dir-default-Freq-R-L-5/)
# version of the code
mrinfo -version
== mrinfo 3.0.3-120-gbb1c2fd4 ==
64 bit release version with nogui, noshared, built Oct 14 2022, using Eigen 3.4.0
<snip>
As one might imagine, our streamlines are garbage on the A/P imaging. I’m at a bit of a loss as to how to debug this issue. Any suggestions?
The scanner creates dec images correctly for both series, as does BrainLab.
If you were to display your vectors with mrview (MRtrix native viewer) instead, you would find that everything looks as expected.
MRtrix uses the scanner/real coordinate frame to represent directional info, whereas itksnap assumes voxel coordinates. This applies to vectors, tensors, SH coefficients, fixels, and tractograms.
Even for the vectors in your example that look ok, there is scope for them to be interpreted (slightly) wrong, for example if you have a (slightly) oblique FOV.
@bjeurissen thank you for the input. I will try looking in the mrview software. Meanwhile, I found that a working study has phase encoding information, while the series referenced above does not contain a PE table:
mrinfo -export_pe_table phase-encoding-ap.txt MR-INNOVATION-20221014/Ax-DTI-70-dir-default-Freq-A-P-2/
mrinfo: [done] scanning DICOM folder "MR-INNOVAT...-70-dir-default-Freq-A-P-2/"
mrinfo: [100%] reading DICOM series "Ax DTI (70 dir-default)Freq A/P"
mrinfo: [ERROR] no phase-encoding information found within image "<REDACTED> [MR] Ax DTI (70 dir-default)Freq A/P"
mrinfo -export_pe_table phase-encoding-lr.txt MR-INNOVATION-20221014/Ax-DTI-70-dir-default-Freq-R-L-5/
mrinfo: [done] scanning DICOM folder "MR-INNOVAT...-70-dir-default-Freq-R-L-5/"
mrinfo: [100%] reading DICOM series "Ax DTI (70 dir-default)Freq R/L"
mrinfo: [ERROR] no phase-encoding information found within image "<REDACTED> [MR] Ax DTI (70 dir-default)Freq R/L"
however, for a 30 direction acquisition from a different scanner, I get a valid PE table:
I will investigate why this particular acquisition to see why there is no PE information available. It would seem that mrconvert assumes L/R phase encoding when the information is not available.
Did you get to the bottom of the original issue? Do the DEC-FA maps come out as expected when displaying in mrview? If not, I do think that’s a bug and will need to be fixed – it would be great to have access to the data if you’re free to share it with us.
Hi @jdtournier, I’ve been trying to use dcm2niix to convert see the thread on GitHub, but haven’t completely determined if it works as expected.
I’d be happy to share a dataset (it’s of me, A/P and L/R 70 direction DTI on two different GE scanners), we have an institutional file sharing system, but it’s rather clunky (you’ll need to send me an email), if you have something easier, please let me know.
