> FYI, Xmedcon has a very nice table of orientations and corresponding
> direction cosines, see:
>
> http://xmedcon.sourceforge.net/docs/orient/medcon3.html
Actually,
This only stores the directions that are aligned to the MR scanners set of
axis'. The acquisition of a a slice is almost never aligned to these axis',
at least not in our hospital. If you want to store the entire orientation
information, you need 9 floats for the orientations (directions of row,
column and slice relative to the scanners set of axis'), and three floats for
the origin. Correct me if I am wrong, but the fields offered by the analyze
format for the origin are integers, and there is no room for 9 floats for the
directions. I would love to be proven wrong, because we had to introduce a
third file that carries this geometrical information. Of course this is not
very comfortable.
Storing this information can be very beneficial for e.g. flirt: aligning a set
of EPI's to a 3D T1 can be much faster if the initial reslice matrix is known
from the (complete) geometrical information. Or for example when a 3D T1 is
registered to a template: on can make sure that the rough orientation is the
same as the template using this (complete) geometrical information.
Cheers,
Erik-Jan
> FYI, Xmedcon has a very nice table of orientations and corresponding
> direction cosines, see:
>
> http://xmedcon.sourceforge.net/docs/orient/medcon3.html
> ----- Original Message -----
> From: "Erik-Jan Vlieger" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Friday, November 01, 2002 6:24 PM
> Subject: Re: image order in SIENA
>
> On Thursday 31 October 2002 22:45, you wrote:
> > Just an aside, I think the Analyze format *can* provide orientation
> > information, so long as it is used correctly. It is a small gamble to
> > trust that it is set correctly by all software in your data processing
> > stream, but the hdr.hist.orient field, when used correctly, can provide
>
> all
>
> > the orthogonal orientation information required. Unfortunately, very
> > little 3rd party software uses this field correctly. I don't know why it
> > is an *optional* field, it would save everyone a lot of headaches if it
> > were used regularly and correctly. For anyone interested in the details,
> > please see a beta attempt to implement handling of this field in the
> > mri_toolbox download at http://eeg.sourceforge.net, where the matlab code
> > there is fully documented. No guarantee that it actually does handle
> > this field correctly, although some beta testing indicates that it works.
>
> Just a question, does this field allow for the three image orientation
> axis' to be stored. which means 9 floats?
> I wanted to store the exact image orientation, and started using a third
> file
> for that.
>
> Thanks,
> Erik-Jan
--
Erik-Jan Vlieger
Academic Medical Center
Dept. of Radiology, G1-209
P.O. Box 22660
1100 DD Amsterdam
The Netherlands
email: [log in to unmask]
Phone: +31 20 5664975
Fax: +31 20 5669753
|