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

Fri May 23 01:53:52 PDT 2014

OK, that is strange - it is supposed to preserve the data ordering as best
it can for NIfTI. I'll file an issue on GitHub and investigate...

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 23 May 2014 09:50, "romain valabregue" <romain.valabregue at upmc.fr> wrote:

>  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>
> 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
>>
>>
>
> _______________________________________________
> 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/20140523/3034d913/attachment-0001.html>