[Mristudio-users] gradient table options

[susumu mori]

Hi Fred,

Here is what we learned about Siemens DICOM so far.
The gradient information you can find in Siemens DICOM is always in the
patient (image) coordinate; Axial/Coronal/Sagittal. So, if that's true, we
don't have to worry anything about oblique angles. So, you SHOULD NOT use
"rotate gradient table", as you pointed out. Of course, this assumes that
you are using VB15, not VB13 and older.

As for why the DICOM gradient information doesn't match the vendor-supplied
gradient table, here is my understanding.

Suppose you do [1, 0, 0] without any oblique angles. Then it should appear
as [1, 0, 0] in DICOM header. However, Siemens actually calculate the exact
solution of diffusion weighting including cross terms with imaging and other
gradient like slice-selective pulses.

For example, in between the two large X diffusion-weighting gradient for [1,
0, 0], there could be crusher gradients and slice-selective gradient along
Z. Then you get X-Z cross-terms. If you solve it exactly, you  actually
can't represent the exact diffusion weighting by simple b-vectors such as
[1, 0, 0.1]. You actually need [bxx, byy, bzz, bxy, bxz, byz]. If you look
into the DICOM header, you can find this b-matrix. This b-matrix is the
exact solution. That means you need a table with  6-element x the number of
orientations, not 3-element x the number of orientations.

Currently we are trying to incorporate this b-matrix information to
DtiStudio.

Next question is, then what is the gradient table (3-element x the number of
orientation), you can find in DICOM. My understanding is, it is an
approximated solution that mimics the exact 6-element table. It's not the
exact solution but close. Good thing about this approximation table is that
it has the conventional gradient table format and can be used as is without
software modification.

So I believe the small deviation of the DICOM gradient table you found from
the vendor-supplied table is the small contribution of the imaging gradient.

I'm not 100% sure about what I said. Once I found out more detail, I'll
share the information here.

I hope this makes sense for you.

Susumu

On Fri, May 21, 2010 at 7:21 AM, Fred <ftam-lists at rotman-baycrest.on.ca>wrote:

> 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. I
> have read all I can find in the email list archive and the forum. It
> makes sense that the DICOM header should contain gradients that are
> already adjusted for the oblique acquisition. I believe you on that.
> However....
>
> I am using Siemens with VB15, mosaic format, and oblique prescription. I
> understand from the email list that I should simply click "Get gradient
> from DICOM file header" and leave "Rotate gradients if applicable"
> *unchecked* because in VB15 the gradient table in the DICOM header is
> already rotated. Is that correct?
>
> What's strange: If my acquisition is straight axial (not oblique), the
> gradient table retrieved by 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?
>
> More discrepancies turn up when comparing dcm2nii and MRIConvert with
> DTIStudio (with/without "Rotate gradients if applicable" option),
> running them against both straight axial and oblique scans:
>
> 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 (and similarly we should not use
> dcm2nii) for Siemens VB15, because that would over-rotate the gradient
> table. Does this sound reasonable?
>
> However, if that is true, then dcm2nii should cause problems for other
> Siemens users. I have not heard of that happening, although I noticed
> one thread on the FSL email list noting the discrepancy.
>
> What's going on and what should we do about it?
>
> Thanks in advance for any input,
> Fred
>
> _______________________________________________
> Mristudio-users mailing list
> Mristudio-users at mristudio.org
> http://lists.mristudio.org/mailman/listinfo/
> Unsubscribe, send a blank email to:
> Mristudio-users-unsubscribe at mristudio.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mristudio.org/pipermail/mristudio-users/attachments/20100526/29da6ccd/attachment.html