Hi Fred,<br><br>Here is what we learned about Siemens DICOM so far.<br>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.<br>
<br>As for why the DICOM gradient information doesn't match the vendor-supplied gradient table, here is my understanding.<br><br>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.<br>
<br>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.<br>
<br>Currently we are trying to incorporate this b-matrix information to DtiStudio.<br><br>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.<br>
<br>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.<br><br>I'm not 100% sure about what I said. Once I found out more detail, I'll share the information here.<br>
<br>I hope this makes sense for you.<br><br>Susumu<br>
<br><div class="gmail_quote">On Fri, May 21, 2010 at 7:21 AM, Fred <span dir="ltr"><<a href="mailto:ftam-lists@rotman-baycrest.on.ca" target="_blank">ftam-lists@rotman-baycrest.on.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'm trying to understand better why the "standard" vectors supplied by<br>
the vendor do not match the DICOM header, and what to do about it. I<br>
have read all I can find in the email list archive and the forum. It<br>
makes sense that the DICOM header should contain gradients that are<br>
already adjusted for the oblique acquisition. I believe you on that.<br>
However....<br>
<br>
I am using Siemens with VB15, mosaic format, and oblique prescription. I<br>
understand from the email list that I should simply click "Get gradient<br>
from DICOM file header" and leave "Rotate gradients if applicable"<br>
*unchecked* because in VB15 the gradient table in the DICOM header is<br>
already rotated. Is that correct?<br>
<br>
What's strange: If my acquisition is straight axial (not oblique), the<br>
gradient table retrieved by DTIStudio from the DICOM header still does<br>
not match the gradient table supplied by Siemens. They are close, but<br>
not close enough to call them equal. Any idea why?<br>
<br>
More discrepancies turn up when comparing dcm2nii and MRIConvert with<br>
DTIStudio (with/without "Rotate gradients if applicable" option),<br>
running them against both straight axial and oblique scans:<br>
<br>
Straight Axial Scan<br>
--------------------<br>
dcm2nii = mriconvert = dtistudio(read dicom) = dtistudio(read dicom +<br>
rotate)<br>
<><br>
dtistudio(siemens + rotate) = siemens<br>
<br>
Oblique Scan (T>C30>S20,inplane10)<br>
-----------------------------------<br>
dcm2nii = dtistudio(read dicom + rotate)<br>
<><br>
dtistudio(read dicom) = mriconvert<br>
<><br>
dtistudio(siemens + rotate)<br>
<><br>
siemens<br>
<br>
Also, none of the gradient tables for the straight axial scan match the<br>
corresponding ones for the oblique scan, so obviously the gradient table<br>
is being adjusted somehow by Siemens before it is stored in the DICOM<br>
header. If that is the case, and we trust the Siemens DICOM field (which<br>
is not clear), we should *not* select the "Rotate gradients if<br>
applicable" option in DTIStudio (and similarly we should not use<br>
dcm2nii) for Siemens VB15, because that would over-rotate the gradient<br>
table. Does this sound reasonable?<br>
<br>
However, if that is true, then dcm2nii should cause problems for other<br>
Siemens users. I have not heard of that happening, although I noticed<br>
one thread on the FSL email list noting the discrepancy.<br>
<br>
What's going on and what should we do about it?<br>
<br>
Thanks in advance for any input,<br>
Fred<br>
<br>
_______________________________________________<br>
Mristudio-users mailing list<br>
<a href="mailto:Mristudio-users@mristudio.org" target="_blank">Mristudio-users@mristudio.org</a><br>
<a href="http://lists.mristudio.org/mailman/listinfo/" target="_blank">http://lists.mristudio.org/mailman/listinfo/</a><br>
Unsubscribe, send a blank email to: <a href="mailto:Mristudio-users-unsubscribe@mristudio.org" target="_blank">Mristudio-users-unsubscribe@mristudio.org</a><br>
</blockquote></div><br>