[Mrtrix-discussion] DISCREPANCY in voxel2world matrices between mrtrix and spm
Donald Tournier
jdtournier at gmail.com
Fri Jun 13 05:00:57 PDT 2014
I should add: for those of you checking out these changes, you'll want to
run this once you're done testing to revert back to the master branch:
$ git checkout master
$ ./build
Cheers,
Donald.
On Fri, Jun 13, 2014 at 12:59 PM, Donald Tournier <jdtournier at gmail.com>
wrote:
>
> 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>*
>
--
*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/debfa762/attachment-0001.html>
More information about the Mrtrix-discussion
mailing list