[Mristudio-users] gradient table options

[Fred Tam]

Thank you! That makes a lot of sense.
Fred



On Wed, 2010-05-26 at 19:21 -0400, susumu mori wrote:
> 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
> 
> _______________________________________________
> 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