Hi,

I have a question hopefully someone can help me with. Thanks in advance!

I just started a scientific internship. I am going to do a study with fMRI and EMG recordings and i have to convert the raw fMRI images to the Nifti format so i can process it with SPM12. 
However, with some folders i get the error message: 

Unable to equalize slice distances: slice order not consistently ascending.
Recompiling with '-DmyInstanceNumberOrderIsNotSpatial' might help.

I have looked for this setting but i cannot seem to find it anywhere. Can someone help me convert my DICOM files?

Kind regards,
Lars

This is a very serious error, and suggests that your DICOM dataset is not complete. The reason you have not found this with a web search is that it is fortunately very rare. The typical solution is to check the providence of your DICOM data and get a copy of the dataset before images have been removed or corrupted.

As ever, it is worth confirming you have the latest version(20190902)  of dcm2niix or if you use the GUI of MRIcroGL. Also, when reporting issues it is helpful if you can report the operating system (MacOS, Linux, Windows) and the scanner you are using (e.g. Siemens Prisma).

With no context, I am going to make a wild guess that you are using a Siemens scanner and acquired field maps. If so, I suspect your issue is described here. Briefly, when acquiring field maps Siemens scanners can generate the same series (0020,0011) and instance (0020,0013) number for the same slice acquired for each of the two echoes. This is technically legal for DICOM (instance numbers do not need to be unique). However, many PACS systems that store DICOM data incorrectly assume that instance numbers ARE unique. In this case, the archival software saves only one of the two images. Through random chance, different echoes are saved for different slices of your volume. Therefore, half the slices from your field map are overwritten. The resulting file is missing images. This is not a limitation of dcm2niix, rather data is missing.

If this is the case, you have two options that are not mutually exclusive:

1.) Go to the MRI console and copy the series directly to a DVD or memory stick. This will provide the raw data.
2.) Update your archiving software so that images with conflicting slices do not overwrite each other. As I recall, different slices still have unique Media Storage SOP Instance UIDs (0002,0003) and this is how a tool should identify whether a DICOM file is unique.
3.) Lobby your Siemens Research Collaboration manager to disambiguate these images - in my experience this is the leading cause for image destruction for Siemens scanners running B-E series software. Given that Instance Number can be any arbitrary value, perhaps Siemens could use "2001" for the first slice of the second echo, "3001" for first slice of second echo, etc. Alternately, these could simply increment the Series number for these echos by 1000, something they already do for other sequences.
4.) If all else fails, here is how you can salvage what remains of your incomplete datasets:
 a.) Use dcm2niix to rename your DICOMs based on series. Assuming your data is in the folder "~/DICOM" and have an empty folder named "~/renamed" you would run "dcm2niix -r y -f %s/%p/%4r.dcm ~/renamed ~/DICOM". Your renamed folder will now have a separate folder for each series in your session.
 5.) Use dcm2niix a normal but once for each of the series folders. You should be able to correctly convert data from all the series except the field map (where images have been lost).

Below is an example of this issue for a Siemens E11C Prisma running PulseSequenceDetails": "%SiemensSeq%_gre_field_mapping" 

First Slice, Echo 1:

(0002,0003) UI [1.3.12.2.1107.5.2.43.67060.2019091914485146558102006] # 52, 1 MediaStorageSOPInstanceUID
(0020,0011) IS [9] # 2, 1 SeriesNumber
(0020,0012) IS [1] # 2, 1 AcquisitionNumber
(0020,0013) IS [1] # 2, 1 InstanceNumber
(0018,0081) DS [5.19] # 4, 1 EchoTime
(0018,0086) IS [1] # 2, 1 EchoNumbers

First Slice, Echo 2: 
(0002,0003) UI [1.3.12.2.1107.5.2.43.67060.201909191448523312502210] # 52, 1 MediaStorageSOPInstanceUID
(0020,0011) IS [9] # 2, 1 SeriesNumber
(0020,0012) IS [1] # 2, 1 AcquisitionNumber
(0020,0013) IS [1] # 2, 1 InstanceNumber
(0018,0081) DS [7.65] # 4, 1 EchoTime
(0018,0086) IS [2] # 2, 1 EchoNumbers

Thank you Chris for your comprehensive reply!
I am not too tech savy so i didnt know i needed to include my specifications so ill do that now.

Operating system: Windows 64bit
Program: MRIcroGL, newest version (downloaded yesterday from this site)
MRI: 3T Philips Achieva 

It seems that i used a Philips scanner while your example used a Siemens scanner. Does this change the fact that i probably have some missing files and should again get the raw data from the scanner. (Im pretty sure my supervisor gave my a direct copy of the raw files from a memory stick. Would this matter or can just copying the files through windows delete files with the same name?)
Or is there now something else that I can do since i didnt use a siemens scanner?

Thanks again for all your help!

Kind regards,
Lars

Reposting this since i got told that my post needed to be reviewed for spam? (originally i posted a link to the exact scanner i used..)

Lars-

I think you will want to check the providence of these images. Possible explanations:
 1. 4D MRI sequence (fMRI/DWI) was interrupted mid-volume, so not all slices are available.
 2. Not all the files were copied to the memory stick.
 3. Data stored in multiple sub-folders (~/dcm/a, ~/dcm/b) and dcm2niix input was subfolder (~/dcm/a) rather than root (~/dcm). This issue would be more common with GE systems that store a maximum of 1000 slices per folder, so a single series can be saved across sub-folders.

In any case, my suggestion of renaming your DICOMs and inspecting each series should be a good starting point. 

Feel free to share a sample dataset directly with me using DropBox, Box or Google Drive. If required, you could anonymize these first (e.g. gdcmanon).

Chris-

After reading your post, I realised that my data also had subfolders which I had seperately put into the converter. After converting my whole datafolder at once, the problem seems to go away. I guess not every required file was stored in the correct subfolder. 
 
If something still doesnt work I'll let you know, but for now it seems that I'm good and can start my analysis.

Thanks again for your immense help!

Lars