[Mristudio-users] gradient table options

[Fred]

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