I've been wrapping mri_convert for use with some of my lab's scripts. I appreciate the work that's been done with this utility and its flexibility in regard to wide support for many formats...the main incentive for moving over to it.
However, recently I've been getting reports of my conversions not behaving well with fsl. I've read the freesurfer archives and am sure the issue is not with mri_convert itself, but with the way I'm using it.
I'll use dcm2nii as a comparison as another lab is using this utility are reports everything appears to work fine.
Example mri_convert:
$ mri_convert mprage.dcm mprage.nii.gz
This command very faithfully converts the dicom to nifti. Inspecting the headers shows that nothing is changed whatsoever.
$ dcm2nii mprage.dcm
This command changes the Patient Orientation header field. In the case of a MPRAGE scan, it is changed from an orientation of PIL (posterior, inferior, left) to PAL. These PAL oriented images are said to be the ones desired.
I can replicate this by using:
$ mri_convert --out_orientation PAL mprage.dcm mprage.nii.gz
Of course, the flip made by dcm2nii for different scan types are themselves different.
The dcm2nii script performs patient orientation changes on all of the scan types I've checked so far (3-5 or so). What I am somewhat perplexed over (and what no one in my lab has been able to answer) is by what "rule" and why are these conversions made? If I knew this, I could ensure mri_convert did them when appropriate.
Would this be the "flipping" from radiological to neurological? Or is this a question I should be posing to the FSL team on the requirements of their images?
Many thanks for any input, and thank you for patience with my newness to this area.
Cheers,
James A. Kyle
Hi Kyle,
first of all don't you probably don't want to use mri_convert in that way -- you should only spec the orientation if it is INCORRECT in the dicom. If it is correct, then the output file will be incorrect. FSL requires that the images be in radiological orientation. One of PIL or PAL are radiological, don't know which.
doug
James Kyle wrote:
I've been wrapping mri_convert for use with some of my lab's scripts. I appreciate the work that's been done with this utility and its flexibility in regard to wide support for many formats...the main incentive for moving over to it.
However, recently I've been getting reports of my conversions not behaving well with fsl. I've read the freesurfer archives and am sure the issue is not with mri_convert itself, but with the way I'm using it.
I'll use dcm2nii as a comparison as another lab is using this utility are reports everything appears to work fine.
Example mri_convert:
$ mri_convert mprage.dcm mprage.nii.gz
This command very faithfully converts the dicom to nifti. Inspecting the headers shows that nothing is changed whatsoever.
$ dcm2nii mprage.dcm
This command changes the Patient Orientation header field. In the case of a MPRAGE scan, it is changed from an orientation of PIL (posterior, inferior, left) to PAL. These PAL oriented images are said to be the ones desired.
I can replicate this by using:
$ mri_convert --out_orientation PAL mprage.dcm mprage.nii.gz
Of course, the flip made by dcm2nii for different scan types are themselves different.
The dcm2nii script performs patient orientation changes on all of the scan types I've checked so far (3-5 or so). What I am somewhat perplexed over (and what no one in my lab has been able to answer) is by what "rule" and why are these conversions made? If I knew this, I could ensure mri_convert did them when appropriate.
Would this be the "flipping" from radiological to neurological? Or is this a question I should be posing to the FSL team on the requirements of their images?
Many thanks for any input, and thank you for patience with my newness to this area.
Cheers,
James A. Kyle _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Thank you, Doug. This is good to know. Is this a general rule? As in, in general, is it bad to change the orientation unless it's incorrect?
If it is not, what would be an appropriate tool to use in conjunction with mri_convert to perform this operation?
*edit* Searching the archives, I found another reference to this.So I'll just post the answer here for anyone who may read this thread:
"consult the FSL website for docs on how to shuffle the pixel data and headers around so that they display properly in fslview (look at avwswapdim and avwreorient)."
-james On Jun 9, 2008, at 8:27 AM, Doug Greve wrote:
Hi Kyle,
first of all don't you probably don't want to use mri_convert in that way -- you should only spec the orientation if it is INCORRECT in the dicom. If it is correct, then the output file will be incorrect. FSL requires that the images be in radiological orientation. One of PIL or PAL are radiological, don't know which.
doug
James Kyle wrote:
I've been wrapping mri_convert for use with some of my lab's scripts. I appreciate the work that's been done with this utility and its flexibility in regard to wide support for many formats...the main incentive for moving over to it.
However, recently I've been getting reports of my conversions not behaving well with fsl. I've read the freesurfer archives and am sure the issue is not with mri_convert itself, but with the way I'm using it.
I'll use dcm2nii as a comparison as another lab is using this utility are reports everything appears to work fine.
Example mri_convert:
$ mri_convert mprage.dcm mprage.nii.gz
This command very faithfully converts the dicom to nifti. Inspecting the headers shows that nothing is changed whatsoever.
$ dcm2nii mprage.dcm
This command changes the Patient Orientation header field. In the case of a MPRAGE scan, it is changed from an orientation of PIL (posterior, inferior, left) to PAL. These PAL oriented images are said to be the ones desired.
I can replicate this by using:
$ mri_convert --out_orientation PAL mprage.dcm mprage.nii.gz
Of course, the flip made by dcm2nii for different scan types are themselves different.
The dcm2nii script performs patient orientation changes on all of the scan types I've checked so far (3-5 or so). What I am somewhat perplexed over (and what no one in my lab has been able to answer) is by what "rule" and why are these conversions made? If I knew this, I could ensure mri_convert did them when appropriate.
Would this be the "flipping" from radiological to neurological? Or is this a question I should be posing to the FSL team on the requirements of their images?
Many thanks for any input, and thank you for patience with my newness to this area.
Cheers,
James A. Kyle _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
In order to help us help you, please follow the steps in: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
James Kyle wrote:
Thank you, Doug. This is good to know. Is this a general rule? As in, in general, is it bad to change the orientation unless it's incorrect?
It is bad to change what the header says the orientation is without changing the actual orientation of the pixel data to match it.
If it is not, what would be an appropriate tool to use in conjunction with mri_convert to perform this operation?
*edit* Searching the archives, I found another reference to this.So I'll just post the answer here for anyone who may read this thread:
"consult the FSL website for docs on how to shuffle the pixel data and headers around so that they display properly in fslview (look at avwswapdim and avwreorient)."
-james On Jun 9, 2008, at 8:27 AM, Doug Greve wrote:
Hi Kyle,
first of all don't you probably don't want to use mri_convert in that way -- you should only spec the orientation if it is INCORRECT in the dicom. If it is correct, then the output file will be incorrect. FSL requires that the images be in radiological orientation. One of PIL or PAL are radiological, don't know which.
doug
James Kyle wrote:
I've been wrapping mri_convert for use with some of my lab's scripts. I appreciate the work that's been done with this utility and its flexibility in regard to wide support for many formats...the main incentive for moving over to it.
However, recently I've been getting reports of my conversions not behaving well with fsl. I've read the freesurfer archives and am sure the issue is not with mri_convert itself, but with the way I'm using it.
I'll use dcm2nii as a comparison as another lab is using this utility are reports everything appears to work fine.
Example mri_convert:
$ mri_convert mprage.dcm mprage.nii.gz
This command very faithfully converts the dicom to nifti. Inspecting the headers shows that nothing is changed whatsoever.
$ dcm2nii mprage.dcm
This command changes the Patient Orientation header field. In the case of a MPRAGE scan, it is changed from an orientation of PIL (posterior, inferior, left) to PAL. These PAL oriented images are said to be the ones desired.
I can replicate this by using:
$ mri_convert --out_orientation PAL mprage.dcm mprage.nii.gz
Of course, the flip made by dcm2nii for different scan types are themselves different.
The dcm2nii script performs patient orientation changes on all of the scan types I've checked so far (3-5 or so). What I am somewhat perplexed over (and what no one in my lab has been able to answer) is by what "rule" and why are these conversions made? If I knew this, I could ensure mri_convert did them when appropriate.
Would this be the "flipping" from radiological to neurological? Or is this a question I should be posing to the FSL team on the requirements of their images?
Many thanks for any input, and thank you for patience with my newness to this area.
Cheers,
James A. Kyle _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
In order to help us help you, please follow the steps in: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
freesurfer@nmr.mgh.harvard.edu