Hello, list. I've asked about the following on the DTIStudio email list,
but the discussion may be a little more appropriate here because it
points at a possible problem with applying dcm2nii to extract bvecs from
Siemens VB15 DTI data (and probably VB17), when the acquisition is
oblique. I understand dcm2nii and MRIConvert are two popular choices
among FSL users, so I wonder if any of you have noticed this?
(context: in the FSL email list archive, I notice a discussion back in
April called "which bvecs to trust?" which started along these same
lines but didn't come to a conclusion.)
I'm trying to understand better why the "standard" vectors supplied by
the vendor do not match the DICOM header, and what to do about it.
According to what I read in the DTIStudio email list archive, all the
major MRI vendors generate DICOM headers containing gradient tables that
are already rotated to account for oblique acquisitions. This includes
Siemens VB15 and above (although not the older Siemens versions). The
bvecs certainly change when you rotate the scan plane on our VB15
system, so it's probably true. However....
What's strange: If my acquisition is straight axial (not oblique), the
gradient table retrieved by dcm2nii/mriconvert/DTIStudio from the DICOM
header still does not match the gradient table supplied by Siemens. They
are close, but not close enough to call them equal. Any idea why?
Even worse: More discrepancies turn up when comparing the bvecs from
dcm2nii, MRIConvert, and DTIStudio (with/without "Rotate gradients if
applicable" option), running them against both straight axial and
oblique scans (30-direction MDDW):
Straight Axial Scan
--------------------
dcm2nii = mriconvert = dtistudio(read dicom) = dtistudio(read dicom +
rotate)
<>
dtistudio(siemens + rotate) = siemens
Oblique Scan (T>C30>S20,inplane10)
-----------------------------------
dcm2nii = dtistudio(read dicom + rotate)
<>
dtistudio(read dicom) = mriconvert
<>
dtistudio(siemens + rotate)
<>
siemens
Also, none of the gradient tables for the straight axial scan match the
corresponding ones for the oblique scan, so obviously the gradient table
is being adjusted somehow by Siemens before it is stored in the DICOM
header. If that is the case, and we trust the Siemens DICOM field (which
is not clear), we should *not* select the "Rotate gradients if
applicable" option in DTIStudio for Siemens VB15 data.
Similarly, we should not use dcm2nii for VB15, because that would rotate
the bvecs unnecessarily. MRIConvert seems to pass along the bvecs from
the DICOM header untouched. In fact, looking at the revision history of
MRIConvert, one of the bug fixes made a year ago was "bvecs for latest
syngo not incorrectly rotated", and a year before that "GE DTI sequences
no longer correct the bvecs for rotation (which was incorrect)." dcm2nii
probably needs a similar fix. I notice the example DTI dataset posted on
the web site with dcm2nii is a VB13 dataset, which *would* have needed a
rotation. Does this sound reasonable?
However, if that is true, then dcm2nii should have caused problems for
other Siemens users. Has anyone noticed?
This doesn't account for the mismatch with the official Siemens tables,
but I suppose I should ask them about it, unless one of you already has.
My tests above were just looking at bvecs generated by the different
software. I have time to scan a human subject this week a)
straight-axially and b) at a large angle like T>C30>S30+inplane30, if
that would clear up anything.
Thanks in advance for any input,
Fred
