[Mrtrix-discussion] DISCREPANCY in voxel2world matrices between mrtrix and spm
Donald Tournier
jdtournier at gmail.com
Fri Jun 13 04:59:09 PDT 2014
Hi Romain (and anyone else willing to help out),
I've just made a few changes to how image strides are handled, which should
get rid of the mismatch you reported between input and output NIfTI files,
at least in most cases. I'd be grateful if you could have a play around
with it and make sure it behaves as expected before I commit the changes to
the main master branch... Currently these changes reside in a branch called
'nifti_strides'.
To do this:
$ git pull
$ git checkout nifti_strides
$ ./build
And then run whatever commands you want to check everything works as
expected - the more the better...
Cheers!
Donald.
On Fri, May 23, 2014 at 9:53 AM, Donald Tournier <jdtournier at gmail.com>
wrote:
> 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
>>
>>
--
*Dr J-Donald Tournier (PhD)*
*Senior Lecturer, **Biomedical Engineering*
*Division of Imaging Sciences & Biomedical EngineeringKing'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
<http://www.kcl.ac.uk/medicine/research/divisions/imaging/departments/biomedengineering>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20140613/5842d6a3/attachment-0001.html>
More information about the Mrtrix-discussion
mailing list