Hi Fred,
the diffusion vector data in Siemen's DICOM header are 'back' calculated from the b-matrix. Prior to VB17 this could in some occasions lead to a 'wrong' inverse solution. It has been fixed from VB17 on. Small differences between the Siemens solution and the other software are due to the fact that Siemens accounts for the impact of the imaging gradients on the effective b-matrix. Thus, anything stored in the DICOM header from VB17 on should be authorative and the best available solution. I think Jolinda's MRIConvert now uses these entries.
Also: Siemens follows the DICOM conventions, i.e. all data are stored in the patient coordinate system (as opposed to the magnet's XYZ or the sequence's PRS). Normally, diffusion gradients are applied in XYZ, therefore Siemens values from the DICOM header ARE ALREADY rotated according to the slice angulation.
Does that make sense?
Cheers-
Andreas
________________________________________
Von: FSL - FMRIB's Software Library [[log in to unmask]] im Auftrag von Fred Tam [[log in to unmask]]
Gesendet: Mittwoch, 26. Mai 2010 03:03
An: [log in to unmask]
Betreff: [FSL] DTI bvecs - dcm2nii vs. mriconvert vs. dtistudio vs. siemens VB15 official tables
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
|