<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi donald<br>
<br>
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)<br>
<br>
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)<br>
<br>
This is an old subject we already discuss (and I keep trying ...)<br>
(<a class="moz-txt-link-freetext" href="http://www.nitrc.org/pipermail/mrtrix-discussion/2013-September/000762.html">http://www.nitrc.org/pipermail/mrtrix-discussion/2013-September/000762.html</a>)<br>
<br>
<br>
I though you will change this for the new mrtrix, but I saw
strange output orientation<br>
<br>
<br>
<br>
For instance I start with my dwi dataset having this orientation :
<br>
<br>
mrinfo data_B2000.nii <br>
Data strides: [ -1 2 3 4 ]<br>
<br>
I perform a tensor fit<br>
<br>
dwi2tensor data_B2000.nii -grad grad.b dti.nii<br>
<br>
but I end up with :<br>
mrinfo dti.nii <br>
Data strides: [ 2 3 1 4 ]<br>
<br>
So a different data order (and a strange one!)<br>
<br>
<br>
Many thanks<br>
<br>
<br>
Romain<br>
<br>
<br>
Le 22/05/2014 10:32, Donald Tournier a écrit :<br>
</div>
<blockquote
cite="mid:CAHgym8JBOUGfr64_wDLY-dxA=HXmx3_gxkfEC3p0JK93FKYptA@mail.gmail.com"
type="cite">
<p dir="ltr">Hi Alessandro,</p>
<p dir="ltr">Just to add to what Romain said, there's a few things
that affect that transform matrix. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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: <a
moz-do-not-send="true"
href="http://www.brain.org.au/software/mrtrix/general/formats.html#dataorder">http://www.brain.org.au/software/mrtrix/general/formats.html#dataorder</a>).
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.</p>
<p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<p dir="ltr">In any case, I hope this makes some kind of sense...
</p>
<p dir="ltr">Cheers,<br>
Donald</p>
<p dir="ltr">--<br>
Dr J-Donald Tournier (PhD)</p>
<p dir="ltr">Senior Lecturer, Biomedical Engineering<br>
Division of Imaging Sciences & Biomedical Engineering<br>
King's College London</p>
<p dir="ltr">A: Department of Perinatal Imaging & Health,
1st Floor South Wing, St Thomas' Hospital, London. SE1 7EH<br>
T: +44 (0)20 7188 7118 ext 53613<br>
W: <a moz-do-not-send="true"
href="http://www.kcl.ac.uk/medicine/research/divisions/imaging/departments/biomedengineering">http://www.kcl.ac.uk/medicine/research/divisions/imaging/departments/biomedengineering</a><br>
</p>
<div class="gmail_quote">On 21 May 2014 15:41, "romain valabregue"
<<a moz-do-not-send="true"
href="mailto:romain.valabregue@upmc.fr">romain.valabregue@upmc.fr</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hello,<br>
<br>
from what I understand this is 2 view of the same
transformation matrix<br>
mrtrix give the transformation matrix relative to a fix
given order of the voxel<br>
so the Data layout says [-0 1 2]<br>
this is why the first number 1 is then -1.75
(-1*voxelsize) in spm<br>
<br>
This flip will then change also the corresponding
translation<br>
the discrepencie in y and z translation are due to the
fact that matlab indices start at 1<br>
<br>
Anyway you should use the transformation given by spm<br>
<br>
Romain<br>
<br>
Le 21/05/2014 16:01, Alessandro Calamuneri a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi there,
<div>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 </div>
<div><br>
</div>
<div>Dimensions: 128x128x4</div>
<div>voxel size: 1.75x1.75x2</div>
<div>Data layout: [-0 1 2]<br>
</div>
<div>data scaling: offset=0 multiplier=1</div>
<div>Transform 1 0 0 -109.8</div>
<div> 0 1 0 -100.2</div>
<div> 0 0 1 -44.73</div>
<div> 0 0 0 1</div>
<div><br>
</div>
<div>Now, when I look at the same transformation matrix
by using SPM on matlab, I get the following
transformation matrix</div>
<div><br>
</div>
<div>V.mat=</div>
<div><br>
</div>
<div>-1.75 0 0 114.7</div>
<div> 0 1.75 0 -101.95</div>
<div> 0 0 2 -46.729</div>
<div> 0 0 0 1</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>How can I be sure to get the correct intensities at
proper voxel coordinates?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Alessandro</div>
<div><br>
</div>
<div>
<div dir="ltr">
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Mrtrix-discussion mailing list
<a moz-do-not-send="true" href="mailto:Mrtrix-discussion@www.nitrc.org" target="_blank">Mrtrix-discussion@www.nitrc.org</a>
<a moz-do-not-send="true" href="http://www.nitrc.org/mailman/listinfo/mrtrix-discussion" target="_blank">http://www.nitrc.org/mailman/listinfo/mrtrix-discussion</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Mrtrix-discussion mailing list<br>
<a moz-do-not-send="true"
href="mailto:Mrtrix-discussion@www.nitrc.org">Mrtrix-discussion@www.nitrc.org</a><br>
<a moz-do-not-send="true"
href="http://www.nitrc.org/mailman/listinfo/mrtrix-discussion"
target="_blank">http://www.nitrc.org/mailman/listinfo/mrtrix-discussion</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>