Hi John,
Sorry for the delay, but I'll chime in with some additional information
that you may be interested in.
The issue of how oblique acquisitions are handled by various vendors and
DICOM conversion programs is a complicated one. The following applies
specifically to the Siemen's platform.
1) In Siemen's DICOMs, the B_matrix and DiffusionGradientDirections
entries in the DICOM are stored in the +LPS frame of reference (relative
to the magnet) that defines the DICOM standard. This means that they
NEED TO BE ROTATED in the case of oblique acquisitions if you want the
bvecs and/or B_matrix to specified relative to the imaging grid. But it
also means that you need to "rotate" the bvecs in the case of strictly
coronal or sagittal acquisitions as well.
2) Commonly used conversion packages handle the bvec rotation issue
different DEPENDING ON THEIR VERSION. Specifically, until Revision 203,
Jolinda Smith's MRIConvert did NOT rotate the bvecs for oblique Siemen's
acquisitions, which was incorrect. The behavior is even more
complicated for previous versions of Chris Rordens' dcm2nii -- at one
point there were dcm2nii versions that were not rotating for Siemens
data acquired under software VB15/VB17, but were rotating bvecs for data
acquired under VB13, when in actuality the correct behavior should have
been rotating the bvecs from oblique acquisitions from ALL 3 Siemen's
software versions.
3) The CURRENT version of dcm2nii by default rotates the bvecs for
oblique acquisitions from all Siemen's software versions. However, the
user can control the default behavior by modifying a setting in the
dcm2nii.ini file.
4) Chris, Jolinda, and myself put together a document back in March on
these issues that can be accessed from the "Word document" link under
Item 8 of Sample Datasets from this web page:
http://www.cabiatl.com/mricro/mricron/dcm2nii.html
or accessed directly via:
http://www.cabiatl.com/mricro/mricron/bvec.doc
5) In principle, using the B_matrix itself in the DICOM is most accurate
since it represents the actual B_matrix (accounting for imaging
gradients), whereas the bvecs (i.e., DiffusionGradientDirection) are
derived (presumably by some sort of principle component analysis on the
B_matrix). That is perhaps the reason that it was recommended to you to
use the B_matrix data stored in the DICOM rather than the
DiffusionGradientDirection entries. However, to my knowledge, most
packages (including FSL) are set up to use bvecs as inputs, not the
B_matrix itself. And even if you could use the B_matrix as an input,
you would still need to rotate it for oblique or non-axial acquisitions.
6) Because the B_matrix (and by extension the
DiffusionGradientDirections) account for the imaging gradients, their
values will differ somewhat across subjects EVEN IF you have a strictly
axial acquisition. So, just because bvecs are not identical across
subjects, that in itself is NOT evidence that a rotation correction was
applied by a given DICOM conversion tool.
7) Further complicating the whole situation is that for the VB13
release, while the B_matrix field in the DICOM is correct (within the
+LPS DICOM frame), the DiffusionGradientDirection data (which is what is
used by MRIConvert and dcm2nii) is sometimes just wrong, due to a bug in
the manner in which Siemen's converted the B_matrix to a principle
diffusion direction. This was fixed with VB15, for which the
DiffusionGradientDirection is correct up to polarity, and in VB17 it was
fixed so that even the polarity is correct. I have no idea how
extensive this bug is in data from the VB13 release.
Hope that helps :)
cheers,
-MH
On Thu, 2011-10-06 at 14:00 +0000, West, John D. wrote:
> Dr. Gutman,
>
> Thanks very much. This is very helpful. In all the time working with DTI, getting the directions correct has always been the biggest hurdle, so it is nice to know that dcm2nii accounts for angulations. Typically we try to avoid oblique slices, but one case we had recently made it unavoidable. We noticed with this case that the vectors supplied by dcm2nii were different from those in the DICOM header, which is what prompted the question. It's good to get that clarified.
>
> Thanks very much for all your help. It sounds like dcm2nii is handling all the different issues accurately so that is good to know. We'll stick with that unless someone else chimes in.
>
> -John
>
> -----Original Message-----
> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of David Gutman
> Sent: Thursday, October 06, 2011 9:45 AM
> To: [log in to unmask]
> Subject: Re: [FSL] Using b-matrix for dtifit
>
> So someone else may correct me... but to clarify..
>
> dcm2nii actually exports the "angulation corrected" b-matrix....
>
> It's been a while since I looked in great detail-- the easiest way to
> do sanity checks is actually look at the generated "bvecs" file
> produced by DMC2NII for 10 subjects scanned with the "same" scan
> parameters..
>
> If there is NO angulation applied... all the bvecs should be the same
> across all of your subjects...
> If instead you notice variations that vary from patient to patient (at
> least among those with different slice angulations).... you can feel
> confident it's giving you the "fixed" numbers.
>
> In the simplest case... you may set the following gradients in the
> scanner console
> 1 0 -1
> 0 0 1
> 0 0 -1
> 0 1 0
> -1 -1 0
> (or whatever)
>
>
> IF you acquiring at an angulation... instead of getting "1"'s.. you'll
> get 0.99 0 -0.99 (or whatever)...
> Actually I think dcm2nii outputs the data so that X2+yz+z2 = 1 .... so
> your numbers may appear slightly difference..
>
>
> But long story short--- if you have 10 subjects with 10 angulations
> using the same exact protocol... if there bvecs files all return
> slightly different numbers (Which makes sense if you account for
> angulation)... then you "know" it's likely exporting the right numbers
>
>
> dg
>
>
> On Thu, Oct 6, 2011 at 9:38 AM, West, John D. <[log in to unmask]> wrote:
> > Dr. Gutman,
> >
> > Thanks very much for the reply. We actually typically use dcm2nii for all our DTI processing, but since the developer recommended using the b-matrix, we wanted to try that out. However, from what you say below it may actually be less accurate is that right?
> >
> > Since you have experience with dcm2nii, do you know if it also corrects the bvecs for scans acquired with oblique slices?
> >
> > Thanks for all the help!
> > -John
> >
> > -----Original Message-----
> > From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of David Gutman
> > Sent: Wednesday, October 05, 2011 5:39 PM
> > To: [log in to unmask]
> > Subject: Re: [FSL] Using b-matrix for dtifit
> >
> > Have you tried MRICONVERT or dcm2nii (part of Mricron)....
> >
> > http://lcni.uoregon.edu/~jolinda/MRIConvert/
> >
> > http://www.cabiatl.com/mricro/
> >
> > Both of those have the ability to extract these bvals/bvecs directory
> > from the siemens private tag--- presuming your WIP DTI sequence isn't
> > much different from the ones we've used, it should be able to pull the
> > bvecs/bvals directly to text files in an FSL friendly format. The
> > "theoretical" b-matrix that is implemented in the scanner console can
> > get affected based on scan angulation and other factors, so these tags
> > generally support the ACTUAL b-matrix applied as opposed to the one
> > specified in the WIP itself (which the scanner may not be able to
> > actually obtain)....
> >
> >
> > On Wed, Oct 5, 2011 at 5:23 PM, West, John D. <[log in to unmask]> wrote:
> >> Hello.
> >>
> >> We are currently running a WIP DTI sequence on our Siemens systems for which the developer recommends using the b-matrix located in the dicom header for calculating the diffusion tensor. Is there a way to run dtifit using this matrix rather than the bval and bvec files? Thanks for your help.
> >>
> >> -John West
> >>
> >
> >
> >
> > --
> > David A Gutman, M.D. Ph.D.
> > Assistant Professor of Biomedical Informatics
> > Senior Research Scientist, Center for Comprehensive Informatics
> > Emory University School of Medicine
> >
>
>
>
|
