I acquired fMRI data using a GE scanner and used dcm2niix to convert the dcm to nii. When I looked at the nii output, the output name contained the suffix “_Eq”. After googling, I realized that this suffix indicates when the number of slices is incomplete or missing. I checked my dcm and found that one slice was missing. I’m curious now if there is any way to convert the dcm into niftis when a slice is missing? Is there a placeholder file that I can create so that it tricks the dcm2niix conversion into thinking that the missing slice is present?
Well, you are going to have to defeat safeguards built into dcm2niix. I would strongly encourage an audit to work out why an image was lost to prevent future issues. Here would be my Hail Mary to resolve this (assuming GE MRI images):
Use the ‘-r y’ mode to rename all of your images by instance number. While the DICOM format does not require instance number to be sequential (or even unique) we can take advantage of the fact that GE graciously orders instance number by slice position and then temporal volume. So you would run:
dcm2niix -r y -f %t/%s_%p/%4r.dcm -o ~/Path/For/Renamed ~/Path/to/DICOMs
Identify the number of images in your volume. If you do not know this, you can use dcmdump to check the first image in the volume: dcmdump --search 0020,1002 0001.dcm. For our example lets assume there are 72 slices per volume:
(0020,1002) IS [72] # 2, 1 ImagesInAcquisition
Identify the missing image and replace it with the same slice from the next (or previous) volume while updating the instance number. For an example, assume the file 0014.dcm is missing, since we have 72 slices we can make a copy of 0086.dcm and rename the copy 0014.dcm. change the instance number (0020,0013) to the missing value. For this example I will use gdcmanon
While these changes are sufficient for dcm2niix, the resulting DICOMs are not archival quality and may not survive being transferred by a PACS. For completeness, for the gdcmanon step you may also want to assign new UIDS, in particular MediaStorageSOPClassUID (0002,0003) and SOPInstanceUID (0008,0018). Be aware that some sequence specific tags might be wrong that could influence the output - you may want to look here for details. For example, the private RTIA Timer (0021,105E) tag for some sequences, or DWI details.
Be aware that this trick will not work for Philips data, that can assign instance numbers in a random order. Also, Philips systems use different methods for identifying volume number depending on whether the sequence was ASL, DWI, etc. For Philips users in this situation, I would work with your Philips research collaboration manager to help create a missing slice. While you are at it, you may want to ask them to lobby Philips to use meaningful sequential numbers for tags.