• It is true that the ANALYZE file header does not contain orientation information. However, the Debabeler translation assumes that the ANALYZE file has been written using the SPM orientation, and so adds an orientation to the NIFTI file it creates. MRIcro apparently does notadd an orientation.

• Thanks again for your explanation. As you said, when converting dicom file to analyze format, it loses the information about orientation, etc. As a result, there should not be any orientatin information in an analyze file header. So If I convert an analyze pair to nifti format using Debabeler and FSL, both results should not contain any orientation information(I think the results should be the same). But why the retult files are different and MRIcro only shows warning messages when opening the nifti file created by Debabeler? I attached an analyze pair and two nifti files created by Debabeler and FSL. Could you please take a look? dicom-1.img and dicom-1.hdr are the analyze files for test. dicom-1_FSL.nii was converted by FSL avwchfiletype dicom-1_Debabeler.nii was converted by Debabeler using AnalyzeToNifti_18Feb2005.xml mapping file. Thank you very much.

• Technically, both the Debabeler and FSL avwchfiletype programs are mapping the NIFTI fields correctly. The Debabeler uses the "recommended" method, whereas FSL avwchfiletype uses the old ANALYZE method (which created problems and motivated people to define NIFTI!). Please keep in mind that the ANALYZE file format does not contain information about the orientation of the scanned subject. When someone sends you an ANALYZE file, you cannot be sure which way the subject's right/left are. Yes, there is a hard-to-find implicit assumption as to what the orientation is, but in reality few people follow it (e.g., radiologists and neurologists flip right/left and create ANALYZE files the way they want to). I expect that the MRIcro warnings are telling you that you have some type of orientation problem with your data. When you created your ANALYZE file, you effectively removed the orientation and lost the ability to determine the subject's left/right. So you might get rid of the warnings by first converting to ANALYZE, but you may in effect be deceiving yourself by removing information that you should know. You can read more about the NIFTI standard by going to their web site and downloading the C source code (look at the comments in nifti1.h). For your convenience, I have attached to this email a segment from that file that I think is relevant here.

• Thanks for your response. The nifti file converted with the mapping xml you sent me can be opened by fslview. However, MRICro(Windows version) still gives warning message. So I did the following test: I converted a dicom file to analzye format using debabler. Then I converted the analyze file to nifti format using both debabeler and avachfiletype(a tool in FSL). I found that the nifti file converted by FSL/avwchfiletype can be opened by MRICRO without any warning message while the one converted by debabeler can not. I checked the fields in the header of the two nifit files(converted with debabeler and FSL avwchfiletype). I found that the following fields are different: qform_code: 1(debabeler) 0(avwchfiletype) || scl_slope: 0(debabeler) 1(avwchfiletype) Does this indicate either debabeler or FSL avwchfiletype maps the fields in NIFTI header incorrectly?

• I converted the Siemens Mosaic DICOM file you sent to NIFTI and tried it in FSLview. The message I saw was: This program has not been compiled for this data type Finished which means that FSLview doesn't support 16-bit unsigned short data. But your data doesn't need that precision. So I tried specifying it as 16-bit signed data and it worked for me; please see the attached. (If you compare the attached translation with the one you have, the only difference is that the "datatype" is now 4 instead of 512). As for MRIcro, I downloaded the linux version but I don't see any option to load a NIFTI file. At any rate, I think the message is warning you that you are attempting to combine two data sets that are not in the same 3d space. So it doesn't appear to be a file conversion issue.

• I found that the Nifti file converted by using AnalyzeToNifti_18Feb2005.xml can not be opened with FSLview. Another viewer, MRICRO can open the file but shows some warning messages below: The Nifti file specifies an affine rotation [QForm>0]. MRICro will display the raw data. Warning: The nifti image includes a rotation transformation. You should reslice the data before attempting overlay the image. Also the same problem occurs when using DicomSiemensMosaicToOneFileNifti_05Apr2006.xml to convert Siemens Mosaic Dicom data to Nifti format. I have attached two dicom files I tried to convert. One is in standard dicom format, the other is in siemens mosaic dicom format. Could you please have a look?

• Yes, you can specify it to be whatever you like. Please see the Debabeler_Usage.pdf in the doc directory, bottom of page 13.

• Thank you for your help. DicomSiemensMosaicToAnalyze_10Sep2004.xml does not work for my data. It works when using xml/contrib/RogerMosaicAndRegular_24Nov2004.xml. Is there a way to change the default output files' location in RogerMosaicAndRegular_24Nov2004.xml?

• Have you tried the translations: xml/contrib/RogerMosaicAndRegular_24Nov2004.xml xml/DicomSiemensMosaicToAnalyze_10Sep2004.xml in the Debabeler XML directory? If these don't work, I may have to ask you for a sample of your data to make a better determination.

• I am trying to use LONI Debabler to convert EPI fMRI dicom data to analyze or nifti format. However I found that debabeler can not convert them correctly using the existing mappings. Is there a way to customize the mapping so that it can recognize and convert epi fMRI data or do you have any mapping xml file for epi fmri dicom conversion?

Topic permissions

• Set ALLOWTOPICCHANGE = DebabelerGroup