[Mrtrix-discussion] DISCREPANCY in voxel2world matrices between mrtrix and spm
romain valabregue
romain.valabregue at upmc.fr
Mon Jun 16 08:48:17 PDT 2014
Hello
Thanks for this changes this will really helps for software
interoperability.
It seems to works good for the few command I test
dwi2tensor tensor2metric tckmap dwi2fod
other function like mrcalc mrmath mrresize was already working with the
previous version (and they are still working)
There is still a bug with the function
mrtransform
for instance if I try to reslice an axial fa into T1 (which is in
sagital acquisition) the output is still in axial (ie data strides 1 2 3
instead to be 3 1 2 (sagital))
I use mrtransform fa.nii -template anta_sagital.nii rfa.nii
Thanks
Romain
Le 13/06/2014 13:59, Donald Tournier a écrit :
>
> 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
> <mailto: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 <mailto: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
>> <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
>>
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> *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, 1^st 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20140616/53cc66a5/attachment-0001.html>
More information about the Mrtrix-discussion
mailing list