OK, so I find that mri_convert, without any -i?d or -o?d specifications does a fine job of reading the axial, unflipped data and it correctly outputs a coronal, flipped volume. So, my concern is how to output an axial unflipped volume correctly. I'm not getting the right answer using the -o?d flags. Please enlighten me ;-)
Best, Darren
PS, if this email gets through the mail server before the previous email (which has image attachments)...read the text of the previous email below and this message might make more sense :-)
Darren Weber wrote:
Hi,
as best I can determine, the latest version of mri_convert is not using the hdr.hist.orient field correctly. It is using orient=0 as if it is RAS, when it must be LAS. it is also using the flipped values (orient=3-5) incorrectly.
Lets start with an Analyze volume with orient=0 (ie, the default Analyze orientation in axial slices, with +X left, +Y anterior, +Z superior). A display of this volume is attached as ucsf_ag_t1.jpg. Note how the anatomical marker placed on the left cheek appears on the right hand side of the axial slice (+X is LEFT, +Y is anterior, +Z is superior; radiological orientation). The matlab tools I have for reading this give the following:
avw = avw_read('ucsf_ag/mri/analyze/ucsf_ag_t1')
AVW_HDR_READ [v 1.10] ...reading ieee-le Analyze format...done ( 0.02 sec).
AVW_IMG_READ [v 1.9 ] ...reading ieee-le Analyze int16 image format. ...reading axial unflipped orientation ...done (10.05 sec).
avw =
hdr: [1x1 struct] fileprefix: 'ucsf_ag/mri/analyze/ucsf_ag_t1' img: [256x256x200 double]avw.hdr.hist.orient
ans =
0OK, now lets process this volume with mri_convert (to get from 256x256x200 into 256x256x256, 1mm^3 voxels):
Given that freesurfer prefers RAS volumes, we use the following command on this Analyze volume:
mri_convert -iid -1 0 0 -ijd 0 1 0 -ikd 0 0 1 analyze_in.img orig
where the -iid indicates that the left-right direction is LAS rather than RAS. This volume is then correctly oriented within the tkmedit display.
So now, we should be able to convert back from the orig volume into Analyze, with the following command:
mri_convert orig -oid -1 0 0 -ojd 0 1 0 -okd 0 0 1 analyze_out.img
Again, we want to flip in X so we get back an LAS volume. However, mri_convert is using the orient=3 (axial flipped) when it sees -oid -1 0 0.
I stress that the flipped orient values (3-5) are not intended to represent Neurological or Radiological orientation. The flipped values are only designed to be used in movies (so they actually facilitate speed of display for volumetic images on a 2D screen where the pixels are updated from top to bottom of the screen).
Even the default orientation is not correct. This, I think, is a fundamental error of associating freesurfer RAS with Analyze orient=0. The problem is that the orient=0 value is LAS, not RAS! For example, if we specify the following:
mri_convert ${sub}/mri/orig -oid 1 0 0 -ojd 0 1 0 -okd 0 0 1 $sub/mri/analyze/${sub}_orig_axial_las.img >> ${sub}_mri_convert.log
and then check the results with my matlab tools (mri_toolbox at http://eeg.sf.net), we see the graphic attached in ucsf_ag_orig_axial_ras.jpg (note that an anatomical marker was placed on the LEFT cheek and according to orient=0, it should appear in radiological orientation, with +X LEFT, but here it appears as +X RIGHT
- this is wrong!); here are the matlab commands:
avw = avw_read('ucsf_ag/mri/analyze/ucsf_ag_orig_axial_las')
AVW_HDR_READ [v 1.10] ...reading ieee-le Analyze format...done ( 0.02 sec).
AVW_IMG_READ [v 1.9 ] ...reading ieee-le Analyze uchar image format. ...reading axial unflipped orientation ...done (24.39 sec).
avw =
hdr: [1x1 struct] fileprefix: 'ucsf_ag/mri/analyze/ucsf_ag_orig_axial_las' img: [256x256x256 double]avw.hdr.hist.orient
ans =
0I may be missing something about how mri_convert has implemented the allocation of values to the orient field of the header, but it appears to me that it is not working in the manner described in the Analyze 7.5 data format. I refer to the document available at:
http://eeg.sourceforge.net/AnalyzeDirect_ANALYZEformat.pdf
I did not see this problem in the previous version of mri_convert, so I assume this is an initial attempt to implement handling of the orient values in mri_convert. I'm not clear about how you have interpreted this field or verified that mri_convert is working with it correctly. Certainly, there is some inconsistency with my understanding of the field and mri_convert implementation. I 'believe' that my reading and implementation of the format documentation is correct.
Best, Darren
-- Darren L. Weber, Postdoctoral Research Fellow, Room 371-10, China Basin Landing, Dynamic Neuroimaging Laboratory, Department of Radiology, University of California, San Francisco 185 Berry Street, San Francisco, CA 94143-0946
Address for express mail/deliveries: 185 Berry Street. Suite 350 San Francisco, CA 94107
voice:(1) 415 353-9444 fax: (1) 415 353-9421 www: http://dnl.ucsf.edu/users/dweber
"People travel to wonder at the height of the mountains, at the huge waves of the seas, at the long course of the rivers, at the vast compass of the ocean, at the circular motion of the stars, and yet they pass by themselves without wondering."
St. Augustine, 354 430
freesurfer@nmr.mgh.harvard.edu