[Mrtrix-discussion] DISCREPANCY in voxel2world matrices between mrtrix and spm

Thu May 22 01:32:26 PDT 2014

Hi Alessandro,

Just to add to what Romain said, there's a few things that affect that
transform matrix.

First one is that MRtrix gives the transformation from image space in
millimetres, while SPM provides it in voxel coordinates, and hence the
rotation part of the transform matrix is scaled by the voxel sizes. The
translation part (the right column) should be in millimetres from the
origin in both cases.

The second one is that the MRtrix transformation is with respect to the
image axes after having rearranged the transform to a near-axial
orientation - all 90° rotations and flips are captured in the layout field
(documented here:
http://www.brain.org.au/software/mrtrix/general/formats.html#dataorder).
This is why the x axis of the MRtrix transform matrix is still positive,
even though the axis is reversed in SPM. The flip is encoded in the layout
field, as Romain pointed out. I'll explain why we do things that way at the
end of the email.

Finally, the slight shift in the translation column is due to the fact that
the origin refers to the centre of the corner voxel. When the origin flips
to the opposite corner, it'll actually move by n-1 voxels. If you shift it
by n voxels, it'll end up outside the dataset, rather than at the centre of
the corner voxel.

So that should clear up most of these issues. If you're in any doubt, the
simplest thing is probably to look at the Matlab code included in MRtrix to
read & write mif files, which reorders the data to match the expected
Matlab ordering, and so handles a lot of these issues.

If you're interested or wondering why MRtrix separates out the data
ordering part from the transform, the reason is that it makes it much
easier to combine images that are in the same space, but whose data might
be ordered differently. MRtrix often changes the data ordering since many
operations perform better when the data are contiguous on disks and/or RAM,
so the best data ordering depends on whether the operations to be performed
are voxel-wise or volume-wise. Smoothing or filtering in the spatial domain
is most efficient when the data for adjacent voxels are close by on file
(or RAM), since this reduces latency in fetching the values for those
voxels. Conversely, CSD and tractography (amongst others) are fastest when
the values for a given voxel are contiguous (i.e. the SH coefficients are
all stored together per voxel). MRtrix is totally flexible is how the data
can be ordered, and this is why there is a clean separation between the
order of the data on file (the layout), and the orientation of the spatial
axes with respect to the scanner (the transform). If this didn't happen, it
would cause issues when trying to for example apply a mask image to the CSD
output, even though both images might actually be derived from the same
dataset, since the data order might be different between the two depending
on how the various applications that generated them chose to order their
output. People have reported these kinds of issues when trying to use
FSLView to overlay a mask image generated in MRView onto the T1 it was
drawn on, for example.

In any case, I hope this makes some kind of sense...

Cheers,
Donald

--
Dr J-Donald Tournier (PhD)

Senior Lecturer, Biomedical Engineering
Division of Imaging Sciences & Biomedical Engineering
King's College London

A: Department of Perinatal Imaging & Health, 1st Floor South Wing, St
Thomas' Hospital, London. SE1 7EH
T: +44 (0)20 7188 7118 ext 53613
W:
http://www.kcl.ac.uk/medicine/research/divisions/imaging/departments/biomedengineering

On 21 May 2014 15:41, "romain valabregue" <romain.valabregue at upmc.fr> wrote:

>  Hello,
>
> from what I understand this is 2 view of the same transformation matrix
> mrtrix give the transformation matrix relative to a fix given order of the
> voxel
> so the Data layout says [-0 1 2]
> this is why the first number 1 is then -1.75 (-1*voxelsize) in spm
>
> This flip will then change also the corresponding translation
> the discrepencie in y and z translation are due to the fact that matlab
> indices start at 1
>
> Anyway you should use the transformation given by spm
>
> Romain
>
> Le 21/05/2014 16:01, Alessandro Calamuneri a écrit :
>
> Hi there,
> I am triyng to get some paremeters sampling at coordinates of tracks got
> after a probabilistic tractography. When I look at an image, e.g., FA.nii,
> I get, among others, the following info using mrview
>
>  Dimensions: 128x128x4
> voxel size: 1.75x1.75x2
> Data layout: [-0 1 2]
>  data scaling: offset=0 multiplier=1
> Transform 1    0    0    -109.8
>                0    1    0    -100.2
>                0    0    1    -44.73
>                0    0    0         1
>
>  Now, when I look at the same transformation matrix by using SPM on
> matlab, I get the following transformation matrix
>
>  V.mat=
>
>  -1.75         0             0          114.7
>    0          1.75          0         -101.95
>    0           0             2           -46.729
>     0           0             0              1
>
>  In the translation column, there is a consistent offset according, for
> two out of three of those parameters, to voxel dimension, as dTz=2
> dTy=1.75, whereas there seems not to be a reletionship between 114.7 and
> -109.8. I assume this is due to the way in which data are stored and read
> within mrtrix, as a flip should have been occured. By flipping coordinates
> I get 128*-1.75+114.7=109.3., which turns out to show an offset of a few
> millimiters.
> As I want to sample MRI data along the tracts using an own matlab
> implementation, I need to go to volume voxel space by multiplying tracts
> coordinates (that are in mm) by the inverse transformation matrix. But
> given this discrepancy, which transformation matrix should I use? I have
> also tried to overlap tracts to, e.g, the same FA map, on matlab, and this
> displacement seems to occur indeed.
> How can I be sure to get the correct intensities at proper voxel
> coordinates?
>
>  Thanks,
> Alessandro
>
>
>
>
> _______________________________________________
> Mrtrix-discussion mailing listMrtrix-discussion at www.nitrc.orghttp://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>
>
>
> _______________________________________________
> Mrtrix-discussion mailing list
> Mrtrix-discussion at www.nitrc.org
> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20140522/f24bd847/attachment.html>