Salut Romain, <br><br><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I have some question nifti file produce by mrtrix<br>
<br>
_depending on the data type I can not see file in other nifti viewer (fslview or spm)<br>
for instance ( Data type: bitwise)<br></blockquote><div><br></div><div>Yes, bitwise data are rarely supported by other packages, which is a shame since it is in the NIfTI standard.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I guess I can test different output type with mrconvert but I can't find on the docs<br>
which string to give to the -datatype option<br></blockquote><div><br></div><div>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:</div><div>
<a href="http://www.brain.org.au/software/mrtrix/general/formats.html#datatypes">http://www.brain.org.au/software/mrtrix/general/formats.html#datatypes</a></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
_A second point is about the 2 orientation matrix from the nifti header<br>
The sform is correct, but the qform just set an identity 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 orientation to use first, but I would set both orientation identical ...<br></blockquote><div><br></div><div>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... </div>
<div><br></div><div>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.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
_A last point: I have notice that when nifti file are created (based on other nifti file) there is a change of the nifti orientation in the header :<br>
I have orientation with negative pixel size but ater mrconvert it 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 1.6262 -140.284 0 0 0 1<br>
but file produce by mrconvert will then have always positive voxel size<br>
1.71875 0 0 -108.281 -0 1.39752 -1.16425 -33.0028 1.71875e-16 1.00052 1.6262 -140.284 0 0 0 1<br>
<br>
Why not to keep the original nifti header orientation (with both sform and qform set) ... ?<br>
I do not realy understand why this change and I wonder if this imply a reordening of the data matrix<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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:</div>
<div> <a href="http://www.nitrc.org/pipermail/mrtrix-discussion/2009-April/000065.html">http://www.nitrc.org/pipermail/mrtrix-discussion/2009-April/000065.html</a></div><div><br></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;">
Many thanks<br>
<br>
Romain<br>
<br>
______________________________<u></u>_________________<br>
Mrtrix-discussion mailing list<br>
<a href="mailto:Mrtrix-discussion@www.nitrc.org" target="_blank">Mrtrix-discussion@www.nitrc.<u></u>org</a><br>
<a href="http://www.nitrc.org/mailman/listinfo/mrtrix-discussion" target="_blank">http://www.nitrc.org/mailman/<u></u>listinfo/mrtrix-discussion</a><br>
</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>