help > orient2std: dcm2niix_v1.2.20200331 and v1.2.20200707
Showing 1-4 of 4 posts
Oct 19, 2020 07:10 PM | Jenifer Juranek
orient2std: dcm2niix_v1.2.20200331 and v1.2.20200707
Hi Chris Rorden,
I'm preparing a large multimodal MRI dataset for shared access (period of performance started 2013). Although I have already processed the data in-house using well-established pipelines throughout the period of performance (back in the days of dcm2nii before dcm2niix), I'd like to use dcm2niix for this task since *.json files would be created/available to the curators/users of the database.
1) Unlike the original conversion I used (dcm2nii), both the stable release and beta release of current versions of dcm2niix require an extra step for me to get the images to display correctly in FSLeyes (v0.31.2). The orientation labels are displayed correctly in FSLeyes, but the multiplanar views are not correct (although these views display correctly in MRIcroGL). I have found that running fslorient2std fixes the problem such that the multiplanar views look correct (and labeled properly). Is there a setting I need to modify in dcm2niix (i'm using default settings) to eliminate the extra step (fslorient2std)? Particularly puzzling is my observation that the 3D-T1 series displays perfectly fine in FSLeyes without running fslorient2std. However, the 3D-T2, 3D-FLAIR do not...even though they were all acquired in the same plane (sagittal).
Many Thanks for any insight you can provide.
Cheers,
Jenifer
I'm preparing a large multimodal MRI dataset for shared access (period of performance started 2013). Although I have already processed the data in-house using well-established pipelines throughout the period of performance (back in the days of dcm2nii before dcm2niix), I'd like to use dcm2niix for this task since *.json files would be created/available to the curators/users of the database.
1) Unlike the original conversion I used (dcm2nii), both the stable release and beta release of current versions of dcm2niix require an extra step for me to get the images to display correctly in FSLeyes (v0.31.2). The orientation labels are displayed correctly in FSLeyes, but the multiplanar views are not correct (although these views display correctly in MRIcroGL). I have found that running fslorient2std fixes the problem such that the multiplanar views look correct (and labeled properly). Is there a setting I need to modify in dcm2niix (i'm using default settings) to eliminate the extra step (fslorient2std)? Particularly puzzling is my observation that the 3D-T1 series displays perfectly fine in FSLeyes without running fslorient2std. However, the 3D-T2, 3D-FLAIR do not...even though they were all acquired in the same plane (sagittal).
Many Thanks for any insight you can provide.
Cheers,
Jenifer
Oct 19, 2020 08:10 PM | Chris Rorden
RE: orient2std: dcm2niix_v1.2.20200331 and v1.2.20200707
Your comments parallel
https://github.com/rordenlab/dcm2niix/issues/438
I hope to release a new stable release soon that should do a better job detecting different 3D acquisitions. While people find it convenient to losslessly re-orient their images to axial slices, we need to be careful not to reorient EPI scans, otherwise we would disrupt slice timing. I try to err on the side of caution, to protect your data.
With fsleyes, you can open the View Settings window and set the "Display Space" to be "World Space". Perhaps you can contact the FSL team to see if there is a way to make this the default behavior.
If you are planning a large re-conversion, you might want to wait until the next stable release of dcm2niix. Depending on your manufacturer, you may get richer meta data.
https://github.com/rordenlab/dcm2niix/issues/438
I hope to release a new stable release soon that should do a better job detecting different 3D acquisitions. While people find it convenient to losslessly re-orient their images to axial slices, we need to be careful not to reorient EPI scans, otherwise we would disrupt slice timing. I try to err on the side of caution, to protect your data.
With fsleyes, you can open the View Settings window and set the "Display Space" to be "World Space". Perhaps you can contact the FSL team to see if there is a way to make this the default behavior.
If you are planning a large re-conversion, you might want to wait until the next stable release of dcm2niix. Depending on your manufacturer, you may get richer meta data.
Oct 19, 2020 09:10 PM | Jenifer Juranek
RE: orient2std:dcm2niix_v1.2.20200331 and v1.2.20200707
Thanks so much for your insight. Yes, simply changing the settings
in FSLeyes fixed my FSLeyes display problem. I look forward to your
next release...I have 149 multimodal datasets to prepare (all
acquired on a 3T GE scanner) for the database folks. Although, from
my experience, GE is not really well-known for having rich
(non-proprietary) metadata. However, the enhanced Dicom associated
with the Siemens VIDA is also giving me problems since their latest
software release (upgrade from syngo MR XA11 to syngo MR XA20).
Many Thanks for all you do.
Cheers,
JJ
Many Thanks for all you do.
Cheers,
JJ
Oct 20, 2020 11:10 AM | Chris Rorden
RE: orient2std:dcm2niix_v1.2.20200331 and v1.2.20200707
The upcoming version of dcm2niix will extract more meta data [from
GE scans](https://github.com/neurolabusc/dcm_qa_ge). This reflects help from engineers at GE. However, some of these
features are only present in the latest GE software, so will be
unavailable for archival studies.