<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 come back with this old thread in the hope you may change the
way you write nifti file (by changing their nifti original
orientation). <br>
I understand it is more convenient to convert the data into
MRtrix's own representation, but it should not be difficult to
keep a trace of the original orientation and use it for any output
derived ? <br>
<br>
I agree it would not improved mrtrix but it would make the
interoperability easier :<br>
In my case all my data have an original orientation of [-0 +1 +2]
(I do not know why it is so ...) and all mrtrix output will then
be [+0 +1 +2]. <br>
So when I use a too simple program that just read the data as it
is writen on the disque, (like the read_avw fsl function in
matlab) I end up with 2 images that are flip regarding to left and
right.<br>
<br>
I agree that it is then my fault because I did not take account on
the nifti orientation. but when you just have data for the exact
same space, it is quicker to forget about the exact orientation
and just work with matrix ... (for instance to compute the mean fa
within a mask derived from the original images)<br>
To avoid the problem I use to resliced the data (with flirt) so
that they have the exact same nifti orientation (which is not
really efficient to duplicate the data)<br>
<br>
If you are not convince it is not a big deal and I live with it<br>
<br>
Chears and many thanks for this nice software<br>
<br>
Romain<br>
<br>
<br>
Le 14/07/2011 02:47, Donald Tournier a écrit :<br>
</div>
<blockquote
cite="mid:CAPP9hqRQazry6sn8tieUw7CR710=tMrgh_Jqt3ECGJ+dLWVBRA@mail.gmail.com"
type="cite">Hello again,
<div><br>
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank for your quick response. I totally agree about the
recipe of chaos. The nifti definition was a very important
initiative to add the orientation in the header<br>
(the analyze format was just a shame) but The 2 matrix
make it crazy. So a reasonable solution is to make both
matrix identical.<br>
</blockquote>
<div><br>
</div>
<div>Agreed</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
For the last point I am still not convince about the
necessity to change the header (and the data accordingly).
As you said both file are coherent and are display exactly
the same<br>
in mrview (and also in SPM software). But it is not the
case for viewer that display the data matrix (with a bad
handling of the orientation matrix)<br>
For instance with trackvis, the change from mrtrix make it
to swap left and right ...<br>
<br>
Since you seems to handle the orientation properly, why
not to keep the hdr unchanged (for both matrix by the way)
? This will facilitate<br>
interoperability between software.<br>
</blockquote>
<div><br>
</div>
<div>Like I said earlier, once MRtrix reads the NIfTI
header, it is converted into MRtrix's own representation.
One of the operations that happens is to reorient the
transform so that when an axial slice is requested, you
only need to look at the x-y plane, regardless of the
transform. I'm pretty keen to keep things that way. </div>
<div><br>
</div>
<div>That said, in a (distant) future release of MRtrix, you
may well find that this is no longer a problem, and that
the transform will be preserved (for different reasons
though). </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
Since I am beggining to become a new fan of mrtrix, I
think I can mannage it like it is ... but it seems to me
it will though be an improvement ...<br>
</blockquote>
<div><br>
</div>
<div>Well, I'm not sure I would call that an improvement, if
it's only to get around limitations of other packages...
But it can see your point, it would help with
interoperability.</div>
<div> </div>
<div>Glad you like MRtrix though, always nice to hear.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Donald.</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thanks<br>
<br>
Romain<br>
<br>
Donald Tournier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
Salut Romain, <br>
I have some question nifti file produce by mrtrix<br>
<br>
_depending on the data type I can not see file in
other nifti<br>
viewer (fslview or spm)<br>
for instance ( Data type: bitwise)<br>
<br>
<br>
Yes, bitwise data are rarely supported by other
packages, which is a shame since it is in the NIfTI
standard.<br>
<br>
I guess I can test different output type with
mrconvert but I<br>
can't find on the docs<br>
which string to give to the -datatype option<br>
<br>
<br>
Yes, that's the best way to deal with the issue. The
list of data types is in the docs, but maybe not the
most obvious place:<br>
<a moz-do-not-send="true"
href="http://www.brain.org.au/software/mrtrix/general/formats.html#datatypes"
target="_blank">http://www.brain.org.au/software/mrtrix/general/formats.html#datatypes</a><br>
<br>
_A second point is about the 2 orientation matrix
from the nifti<br>
header<br>
The sform is correct, but the qform just set an
identity<br>
orientation (with the voxel size)<br>
why not to set both orientation to the same value
?<br>
I am not sure if it is specify in the nifti
definition which<br>
orientation to use first, but I would set both
orientation<br>
identical ...<br>
<br>
<br>
Yes, you're right, the NIfTI standard does specifies
that both qform and sform can coexist: apparently
you can use whichever you like depending on your
specific application context. MRtrix will always use
the sform if it's available, otherwise the qform is
used. I personally find having two different
transforms in the same file confusing, sounds like a
recipe for chaos to me... <br>
In any case, you're right that there is no reason
why the same transforms can't both be stored in the
header. I might make that change for the next
release.<br>
<br>
_A last point: I have notice that when nifti file
are created<br>
(based on other nifti file) there is a change of
the nifti<br>
orientation in the header :<br>
I have orientation with negative pixel size but
ater mrconvert it<br>
will be change with positive valu<br>
for instance with a sform<br>
-1.71875 0 0 110 0 1.39752 -1.16425 -33.0028
-1.71875e-16 1.00052<br>
1.6262 -140.284 0 0 0 1<br>
but file produce by mrconvert will then have
always positive voxel<br>
size<br>
1.71875 0 0 -108.281 -0 1.39752 -1.16425
-33.0028 1.71875e-16<br>
1.00052 1.6262 -140.284 0 0 0 1<br>
<br>
Why not to keep the original nifti header
orientation (with both<br>
sform and qform set) ... ?<br>
I do not realy understand why this change and I
wonder if this<br>
imply a reordening of the data matrix<br>
<br>
<br>
Yes, this can happen. This is due to the fact that
after loading the image header, MRtrix will modify
the transform if it's not near-axial. This is to
ensure that the x-axis is always as close to
left-right as possible, the y-axis is as close to
posterior-anterior as possible, etc. This also means
that the strides used to navigate around the data
get changed accordingly - in your case, the x-axis
would simply have been inverted. You'll also notice
that the translation x coordinate has changed from
110 to -108.281, since after inverting the x-axis
the 'origin' will now be in the opposite corner. The
data will also have been reordered in the output
file for that reason, but will (or at least should)
always remain consistent with the header. The check
is to display both files in MRView, they should
align perfectly. <br>
Someone else had a related issue displaying a
non-axial NIfTI image in FSLView, and they trying to
overlay another NIfTI image generated with MRtrix
from the same image. The problem was also related to
the fact that MRtrix will change the transform for
non-axial images, and FSLView will not account for
that. More info in this thread:<br>
<a moz-do-not-send="true"
href="http://www.nitrc.org/pipermail/mrtrix-discussion/2009-April/000065.html"
target="_blank">http://www.nitrc.org/pipermail/mrtrix-discussion/2009-April/000065.html</a><br>
<br>
<br>
Cheers,<br>
<br>
Donald.<br>
<br>
<br>
Many thanks<br>
<br>
Romain<br>
<br>
_______________________________________________<br>
Mrtrix-discussion mailing list<br>
<a moz-do-not-send="true"
href="mailto:Mrtrix-discussion@www.nitrc.org"
target="_blank">Mrtrix-discussion@www.nitrc.org</a><br>
</div>
</div>
<mailto:<a moz-do-not-send="true"
href="mailto:Mrtrix-discussion@www.nitrc.org"
target="_blank">Mrtrix-discussion@www.nitrc.org</a>>
<div class="im"><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>
<br>
<br>
<br>
-- <br>
Jacques-Donald Tournier (PhD)<br>
Brain Research Institute, Melbourne, Australia<br>
Tel: +61 (0)3 9035 7033<br>
</div>
</blockquote>
<div>
<div class="h5">
<br>
_______________________________________________<br>
Mrtrix-discussion mailing list<br>
<a moz-do-not-send="true"
href="mailto:Mrtrix-discussion@www.nitrc.org"
target="_blank">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>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Jacques-Donald Tournier (PhD)<br>
Brain Research Institute, Melbourne, Australia<br>
Tel: +61 (0)3 9035 7033<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>