Dear FS Listers,
mri_convert isn't giving me quite what I expected when I use it to reorient an inhomogeneous volume. I apologize in advance if it is my misunderstanding or something that has been covered before. These orientation issues make my head spin (as they do the subject data ;-).
Consider the following example:
% mri_info volume.mgz : dimensions: 256 x 256 x 128 voxel sizes: 1.0000, 1.0000, 1.3300 : Orientation : PIL Primary Slice Direction: sagittal :
I take this volume and reorient it with mri_convert to LIA orientation.
% mri_convert --out_orientation LIA volume.mgz volume_LIA.mgz
But what it gives me back is unexpected.
% mri_info volume_LIA.mgh : dimensions: 256 x 256 x 128 voxel sizes: 1.0000, 1.0000, 1.3300 : Orientation : LIA Primary Slice Direction: coronal
I was first surprised first that mri_convert was resorting to trilinear interpolation. It seems like this kind of transformation could be done with 100% fidelity using nearest neighbor. But the bigger concern is I would have also expected the output dimensions to be 128x256x256 with the voxel sizes 1.33, 1.00, 1.00. It seems like if you reorient a non cubic volume with mri_convert, it arbitrarily cuts some of the data out from the posterior and anterior. tkmedit display seems to confirm this.
To put it another way, I would expect:
mri_convert --out_orientation PIL volume_LIA.mgz volume_PIL.mgz
to generate at volume_PIL.mgz file that was voxel identical to the original volume.mgz.
Thanks for your time.
Ray
did you look at the help for mri_convert concerning the orientation?
On Sun, 16 Dec 2007, Ray Fix wrote:
Dear FS Listers,
mri_convert isn't giving me quite what I expected when I use it to reorient an inhomogeneous volume. I apologize in advance if it is my misunderstanding or something that has been covered before. These orientation issues make my head spin (as they do the subject data ;-).
Consider the following example:
% mri_info volume.mgz : dimensions: 256 x 256 x 128 voxel sizes: 1.0000, 1.0000, 1.3300 : Orientation : PIL Primary Slice Direction: sagittal :
I take this volume and reorient it with mri_convert to LIA orientation.
% mri_convert --out_orientation LIA volume.mgz volume_LIA.mgz
But what it gives me back is unexpected.
% mri_info volume_LIA.mgh : dimensions: 256 x 256 x 128 voxel sizes: 1.0000, 1.0000, 1.3300 : Orientation : LIA Primary Slice Direction: coronal
I was first surprised first that mri_convert was resorting to trilinear interpolation. It seems like this kind of transformation could be done with 100% fidelity using nearest neighbor. But the bigger concern is I would have also expected the output dimensions to be 128x256x256 with the voxel sizes 1.33, 1.00, 1.00. It seems like if you reorient a non cubic volume with mri_convert, it arbitrarily cuts some of the data out from the posterior and anterior. tkmedit display seems to confirm this.
To put it another way, I would expect:
mri_convert --out_orientation PIL volume_LIA.mgz volume_PIL.mgz
to generate at volume_PIL.mgz file that was voxel identical to the original volume.mgz.
Thanks for your time.
Ray
Thanks for looking at my mail and sorry for the late reply. To remind everyone, the issue I raised is about re-orientation with mri_convert where width, height and depth are different.
On Dec 16, 2007, at 10:27 PM, Doug Greve wrote:
did you look at the help for mri_convert concerning the orientation?
I did. Let me try to better re-phrase the problem as I see it.
I wrote a ruby script (attached for fun) to generate a 90x30x10, 8- bit, equal spaced mgh file with all 27,000 voxels set to 255 and the direction cosines set to LIA orientation.
Next, I did
mri_convert --out_orientation PIL test_lia.mgh test_pil.mgh
and examined the output voxels.
The breakdown is:
24,000 voxels are set to zero. 3,000 voxels are set to 255.
The spacial pattern is sort of random looking although I am sure it is related to how it is sampling off-volume.
Is this the expected behavior?
By contrast, if you create a 30x30x30 volume of all 255, the PIL reoriented volume is identical--30x30x30 all 255. Which is completely what I would expect.
Best regards, Ray
freesurfer@nmr.mgh.harvard.edu
-
Doug Greve -
Ray Fix