[Mrtrix-discussion] nifti format
romain valabregue
romain.valabregue at upmc.fr
Thu Sep 5 01:14:17 PDT 2013
Hi Donald
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).
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 ?
I agree it would not improved mrtrix but it would make the
interoperability easier :
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].
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.
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)
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)
If you are not convince it is not a big deal and I live with it
Chears and many thanks for this nice software
Romain
Le 14/07/2011 02:47, Donald Tournier a écrit :
> Hello again,
>
> 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
> (the analyze format was just a shame) but The 2 matrix make it
> crazy. So a reasonable solution is to make both matrix identical.
>
>
> Agreed
>
> 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
> 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)
> For instance with trackvis, the change from mrtrix make it to swap
> left and right ...
>
> Since you seems to handle the orientation properly, why not to
> keep the hdr unchanged (for both matrix by the way) ? This will
> facilitate
> interoperability between software.
>
>
> 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.
>
> 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).
>
> 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 ...
>
>
> 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.
> Glad you like MRtrix though, always nice to hear.
>
> Cheers,
>
> Donald.
>
>
>
> Thanks
>
> Romain
>
> Donald Tournier wrote:
>
> Salut Romain,
> I have some question nifti file produce by mrtrix
>
> _depending on the data type I can not see file in other nifti
> viewer (fslview or spm)
> for instance ( Data type: bitwise)
>
>
> Yes, bitwise data are rarely supported by other packages,
> which is a shame since it is in the NIfTI standard.
>
> I guess I can test different output type with mrconvert but I
> can't find on the docs
> which string to give to the -datatype option
>
>
> 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:
> http://www.brain.org.au/software/mrtrix/general/formats.html#datatypes
>
> _A second point is about the 2 orientation matrix from the
> nifti
> header
> The sform is correct, but the qform just set an identity
> orientation (with the voxel size)
> why not to set both orientation to the same value ?
> I am not sure if it is specify in the nifti definition which
> orientation to use first, but I would set both orientation
> identical ...
>
>
> 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...
> 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.
>
> _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 :
> I have orientation with negative pixel size but ater
> mrconvert it
> will be change with positive valu
> for instance with a sform
> -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
> but file produce by mrconvert will then have always
> positive voxel
> size
> 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
>
> Why not to keep the original nifti header orientation (with
> both
> sform and qform set) ... ?
> I do not realy understand why this change and I wonder if this
> imply a reordening of the data matrix
>
>
> 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.
> 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:
> http://www.nitrc.org/pipermail/mrtrix-discussion/2009-April/000065.html
>
>
> Cheers,
>
> Donald.
>
>
> Many thanks
>
> Romain
>
> _______________________________________________
> Mrtrix-discussion mailing list
> Mrtrix-discussion at www.nitrc.org
> <mailto:Mrtrix-discussion at www.nitrc.org>
> <mailto:Mrtrix-discussion at www.nitrc.org
> <mailto:Mrtrix-discussion at www.nitrc.org>>
>
> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>
>
>
>
> --
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9035 7033
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9035 7033
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20130905/8464b4fc/attachment.html
More information about the Mrtrix-discussion
mailing list