[Mrtrix-discussion] DISCREPANCY in voxel2world matrices between mrtrix and spm
romain valabregue
romain.valabregue at upmc.fr
Fri May 23 01:49:52 PDT 2014
Hi donald
I understand the performance point of view, and just looking how fast
are mrtrix function I am sure you made you good choice. I especially
appreciate that mrtrix can handle all kind of data order or resolution
in a coherent framework. (ie mask from T1 space apply to see on the
diffusion)
But it is only needed for the internal representation of the data. If
you could keep the same header as the original input data (when writing
an output image) it will keep all the data in a coherent orientation
(and make life do much easier for external use)
This is an old subject we already discuss (and I keep trying ...)
(http://www.nitrc.org/pipermail/mrtrix-discussion/2013-September/000762.html)
I though you will change this for the new mrtrix, but I saw strange
output orientation
For instance I start with my dwi dataset having this orientation :
mrinfo data_B2000.nii
Data strides: [ -1 2 3 4 ]
I perform a tensor fit
dwi2tensor data_B2000.nii -grad grad.b dti.nii
but I end up with :
mrinfo dti.nii
Data strides: [ 2 3 1 4 ]
So a different data order (and a strange one!)
Many thanks
Romain
Le 22/05/2014 10:32, Donald Tournier a écrit :
>
> 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
> <mailto: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 list
>> Mrtrix-discussion at www.nitrc.org <mailto:Mrtrix-discussion at www.nitrc.org>
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>
>
> _______________________________________________
> Mrtrix-discussion mailing list
> Mrtrix-discussion at www.nitrc.org
> <mailto: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/20140523/38d406f4/attachment.html>
More information about the Mrtrix-discussion
mailing list