[Mrtrix-discussion] Question about the gradient direction table used in Mrtrix

Sun Apr 7 23:48:45 PDT 2013

Hi Sangma,

I had a look at the values you sent, and I get the right values, although
there are a couple of issues that complicate things. If the mrinfo-supplied
transform matrix is R (only the upper left 3x3 part - i.e. without the
translation terms), and the DICOM-supplied gradient direction is g (=
-0.002, 1.000, 0.000), then R*g is pretty close to the right answer
('0.0025, 0.9989, 0.0459'), although it's the opposite direction to the
MRtrix-supplied gradient. However, it's exact if the y component of g is
inverted (i.e. g = -0.002, -1.000, 0.000), so that presumably is the actual
conversion that's taking place.

I think what is going on is that the MRtrix-supplied transformation matrix
that you're using has been modified by MRtrix to match its coordinate
system, which will probably involve a flip of the x or y axis depending on
the actual row & column direction (cosine) vectors as specified in the
DICOM headers - MRtrix will modify these if they don't point in the
expected left->right and posterior->anterior directions (actually, it does
a fair bit more than that: it reshuffles the matrix around so that the
rotation part is as close to identity as possible, and modify the data
strides to match - it's bit beyond this discussion though). You can verify
whether this is indeed the case by looking at the output of mrinfo: if the
'layout' entry starts with '-0,+1' or '+0,-1', then the transformation
matrix will have been modified from what it was in the DICOM headers and
the images strides modified to match (essentially, a negative sign in the
layout means that the order of traversal of the voxels is backwards for
that axis, if that makes any sense...). If the column (y) vector was
pointing antrior->posterior, then MRtrix will have flipped its direction
and specified a negative stride for that axis, to indicate that the voxel
values are actually to be traversed in the opposite order. This
modification to the transformation matrix happens after the DICOM gradient
import, so the mrinfo-supplied matrix that you're using would be different
from what was actually used to modify the gradients. Hope I'm making sense,
this stuff can get pretty complicated...

Your best bet is to form the transformation matrix yourself from the DICOM
header entry "ImageOrientationPatient" (tag: 0x0020, 0x0037), which
essentially forms the first and second columns of the transformation matrix
(the third is the slice normal vector, which is their cross product). I'm
assuming that this will differ from the mrinfo-supplied matrix in that the
2nd column will be inverted, and so multiplication of the DICOM-supplied
gradient direction by that matrix should now give you the correct answer...

Another way to check is to insert the line:
   VAR (image_transform);
at line 444 of file lib/file/dicom/image.cpp, which will cause the actual
matrix used for this step to be printed on the terminal (you'll to ./build
and ./build install again before these changes take effect).

Hope this helps...
Cheers,

Donald.

On 8 April 2013 13:40, smxie_nlpr <smxie at nlpr.ia.ac.cn> wrote:

> **
> Dear Dr J-Donald Tournier，
>
> Thank you for your help. And I have another question. I have a dataset
> from GE scanner. I get one of the gradient directions is '-0.002, 1.000,
> 0.000' with the command 'dicominfo' in Matlab. The gradient direction
> achieved with the command 'mrinfo' in Mrtrix is '-0.00650699, -0.998944,
> -0.0454892 ', and the transform matrix achieved with 'mrinfo ' is [0.9951
> 0.004517 0.09862 -136.6; -0 0.9989 -0.04591 -104.6; -0.09873 0.04569 0.9941
> -50.04; 0 0 0 1]. Can I transform the direction  '-0.002, 1.000, 0.000' to
> '-0.00650699, -0.998944, -0.0454892 ' with the transform matrix. No matter
> flipping the sign of z component or not, I cannot get '-0.00650699,
> -0.998944, -0.0454892 ' from '-0.002, 1.000, 0.000'. Are there other steps
> for the transfromation to get  '-0.00650699, -0.998944, -0.0454892 ' .
>
>  Thanks.
>
>  Regards,
> Sangma Xie
>
>
>
>
> ------------------------------
>  Sangma Xie , Master
> Brainnetome Center
> National Laboratory of Pattern Recognition (NLPR)
> Institute of Automation, Chinese Academy of Sciences (CASIA)
> 95 Zhong Guan Cun East Road, Hai Dian District, Beijing 100190, P.R.China
>
>
>
>  *From:* Donald Tournier <d.tournier at brain.org.au>
> *Date:* 2013-04-03 11:26
> *To:* smxie <smxie at nlpr.ia.ac.cn>
> *CC:* mrtrix-discussion <mrtrix-discussion at www.nitrc.org>
> *Subject:* Re: [Mrtrix-discussion] Question about the gradient direction
> table used in Mrtrix
>  Hi Sangma,
>
> OK, there's quite a few issues at play here. First off, the convention
> used in MRtrix is that the gradients are specified with respect to the
> DICOM patient coordinate system. This is essentially the same convention as
> for DICOM images produced on Siemens and Philips scanners, and the newer
> standard DICOM tags recently introduced, with one notable exception: the
> DICOM patient-centered coordinate system has its x-axis running
> right-to-left and its y-axis running anterior-posterior, whereas MRtrix
> assumes these axes run in the opposite direction (as per the NIfTI
> standard). So MRtrix will flip the x & y components to account for this.
>
> For Siemens & Philips images, that's essentially all that happens to the
> DW gradients. For GE images, it's a little different, since in this case
> the gradients are (or at least, used to be) stored with respect to the
> images axes. This means that to convert to MRtrix convention, they must be
> re-oriented back into the patient-centered coordinate system. This is what
> the rotate_DW_scheme flag specifies: when the DW gradient information was
> read from a GE-specific tag, this is set to true and the gradients are then
> rotated according to the direction of the images axes. In this case, the z
> component is inverted, since flipping the x & y is essentially the same as
> flipping z, given the symmetry of diffusion.
>
> As far as I know, dcm2nii provides the DW directions with respect to the
> image axes (in the NIfTI coordinate system). To convert these back to
> MRtrix convention, the same transformation as you highlighted is needed,
> but *without* the negative sign. The transform you highlighted also
> accounts for differences in the directions of these axes due to the
> different conventions used for DICOM versus NifTI/MRtrix, so is not
> appropriate as-is to do convert a dcm2nii-supplied gradient table into one
> suitable for MRtrix. This is because the dcm2nii gradient table is provided
> with respect to the image axes in NIfTI coordinate space, and in MRtrix
> they are provided with respect to the original axes, also in NIfTI
> coordinate space.
>
> To get back to your question, what do you mean when you say 'the original
> gradient table'? The one supplied by dcm2nii (in which case converting
> using the highlighted section of code would not work, as explained above),
> or the actual ones as read directly from the DICOM headers? If the latter,
> then unless your images were acquired on a GE scanner, then that also would
> not work, since that section of code would only be used for GE images. If
> you are trying to convert non-GE DW directions read directly from the DICOM
> headers, then all you need to do is flip the sign of the x & y components.
>
> Basically, it's really hard to keep track of all the possible conventions
> and what each step in the processing pipeline might have done to the DW
> gradients. Hopefully the above will help you figure out where the problem
> might be...
>
> Hope this helps.
> Cheers,
>
> Donald.
>
>
> On 3 April 2013 12:57, smxie_nlpr <smxie at nlpr.ia.ac.cn> wrote:
>
>> **
>>  Hi,
>>
>> I have a question about the gradient direction table used in Mrtrix. The
>> gradient direction table achieved from the DICOM images with dcm2nii is
>> different from the table achieved with the command 'mrinfo DICOMDIR -grad
>> encoding.b'. I checked the source code of Mrtrix and found the following
>> codes '
>> if(rotate_DW_scheme)
>>  {
>> G(n,0) = image_transform(0,0) * d[0] + image_transform(0,1) * d[1] -
>> image_transform(0,2) * d[2];
>> G(n,1) = image_transform(1,0) * d[0] + image_transform(1,1) * d[1] -
>> image_transform(1,2) * d[2];
>> G(n,2) = image_transform(2,0) * d[0] + image_transform(2,1) * d[1] -
>> image_transform(2,2) * d[2];
>> }' in image.cpp.
>> I transformed the original gradient table with similar code in Matlab,
>> but the result is not equal to the table achieved with mrinfo. So I want to
>> know the procedure of transforming the original gradients to the gradients
>> achieved with mrinfo. And why is it 'G(n,0) = image_transform(0,0) *
>> d[0] + image_transform(0,1) * d[1] - image_transform(0,2) * d[2];'
>> rather than 'G(n,0) = image_transform(0,0) * d[0] + image_transform(0,1)
>> * d[1] + image_transform(0,2) * d[2];' ?
>>
>> Thanks.
>>
>> Sangma Xie
>> ------------------------------
>>  Sangma Xie , Master
>> Brainnetome Center
>> National Laboratory of Pattern Recognition (NLPR)
>> Institute of Automation, Chinese Academy of Sciences (CASIA)
>> 95 Zhong Guan Cun East Road, Hai Dian District, Beijing 100190, P.R.China
>>
>>
>>
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>>
>>
>
>
> --
> *Dr Jacques-Donald Tournier
> *
> Research Fellow
>
> The Florey Institute of Neuroscience and Mental Health
> Melbourne Brain Centre - Austin Campus
> 245 Burgundy Street
> Heidelberg  Vic  3084
> Ph:  +61 3 9035 7033
> Fax:  +61 3 9035 7307
> www.florey.edu.au
>
>

-- 
*Dr Jacques-Donald Tournier
*
Research Fellow

The Florey Institute of Neuroscience and Mental Health
Melbourne Brain Centre - Austin Campus
245 Burgundy Street
Heidelberg  Vic  3084
Ph:  +61 3 9035 7033
Fax:  +61 3 9035 7307
www.florey.edu.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20130408/4940a559/attachment-0001.html