DCM2NIIX splitting a scan run into multiple files

1

I have some fMRI data that I’ve been trying to convert to BIDS format through my University’s Flywheel instance. I’m running into a problem because a couple of the scan runs are being split into multiple acquisitions by DCM2NIIX on Flywheel. All other scan runs process fine with this pipeline.

I had previously processed these data in a more low-tech way, using a GUI version of DCM2NII / DCM2NIIX, which produced produced single Nifti files for the runs in question.

In one case, it’s a functional run, which I ran all the way through FSL without issue previously. There should be 294 images in the run; it looks like now, one file has 130 images and the other has 164. (Looking back at the files from my old pipeline, the data type of BOLD runs for that subject is INT16, while for other subjects I’ve checked, it’s UINT16. But that’s true for other runs, not just the one at issue. Not sure if that helps…)

The other run at issue is a B0map run, and DCM2NIIX on Flywheel is giving 3 separate output files instead of 1. (So across 2 B0map DICOM sets for that session, there’s a total of 5 outputs where there should only be 3.)

Any ideas as to why this is happening, or how to fix it?

2

I have a similar problem with 44 subjects out of 284 using heudiconv. But I get the same mess with dcm2niix, but I did not had this problem with an older version of dcm2riiix. Do you have Philips data as well? My first idea is the delayed reco of some slices. Philips do not store mosaic images and if the reco is unable to perform online reconstruction of all slices of a volume some slices will be postponed and reconstructed at the end of the scan.

I my case it happend at volume 379 or 380 of 445 if it messed up.

I use fslmerge to glue everthing together.

fslmerge -t outputname.nii.gz `for i in {1…57}; do echo sub-xy_task-mytask_run-1_bold$i.nii.gz | tr ‘\n’ ’ '; done`

1 Like
3

If this issue is reproducible with dcm2niix in the absence of Flywheel, can you open a Github issue. This is probably easiest to resolve if you can share a problematic dataset with me (send DICOMs to me as an archive via Box, DropBox or GoogleDrive, use the email address listed in my Github avatar).

If you want to troubleshoot this yourself:

To isolate a problematic series from series that convert correctly, I would suggest renaming your DICOMs so each series is saved in a separate folder:

dcm2niix -r y -f %t_%s/%5r.dcm -o ~/out ~/path/to/DICOMs

Once you have identified the problematic series, I would suggest including the series instance UID (from 0020,000E) and time of study (from 0008,0020 and 0008,0030) into the output filenames:

dcm2niix -f %s_%p_%t_%s_%j /path/to/DICOMs

My best guess is one of these properties varies within your series. dcm2niix relies on these properties as a recipe to avoid combining series that do not belong together.

4

Thanks!

I just E-mailed you links to the problematic DICOM sets, but I’ll also copy here the output that I get from DCM2NIIX for the two problematic runs.

For a B0map run:

Found 53 DICOM file(s)

Slices not stacked: coil varies

Warning: Interslice distance varies in this volume (incompatible with NIfTI format).

Warning: Missing images? Expected 35 images, but instance number (0020,0013) ranges from 1 to 53

Convert 35 DICOM as /Users/michaelcohen/Downloads/1.3.12.2.1107.5.2.43.66044.2019062011010746995985315.0.0.0.dicom/1.3.12.2.1107.5.2.43.66044.2019062011010746995985315.0.0.0.dicom_B0map_20190620100949_14_c_e2_ph (96x96x35x1)

Warning: Weird CSA ‘ProtocolSliceNumber’ (System/Miscellaneous/ImageNumbering reversed): VALIDATE SLICETIMING AND BVECS

Convert 18 DICOM as /Users/michaelcohen/Downloads/1.3.12.2.1107.5.2.43.66044.2019062011010746995985315.0.0.0.dicom/1.3.12.2.1107.5.2.43.66044.2019062011010746995985315.0.0.0.dicom_B0map_20190620100949_14_cHC1-7_e2_ph (96x96x18x1)

Conversion required 0.103555 seconds (0.098611 for core code).

Here is the output for the functional run from a different session that was also problematic:

Found 294 DICOM file(s)

Slices not stacked: coil varies

UINT16->INT16 Future release will change default. github.com/rordenlab/dcm2niix/issues/338

Convert 130 DICOM as /Users/michaelcohen/Downloads/1.3.12.2.1107.5.2.43.66044.2019102310461968476343384.0.0.0.dicom/1.3.12.2.1107.5.2.43.66044.2019102310461968476343384.0.0.0.dicom_BOLD_mb4_2mm_decision_run2_20191023100140_12_c (98x98x72x130)

UINT16->INT16 Future release will change default. github.com/rordenlab/dcm2niix/issues/338

Convert 164 DICOM as /Users/michaelcohen/Downloads/1.3.12.2.1107.5.2.43.66044.2019102310461968476343384.0.0.0.dicom/1.3.12.2.1107.5.2.43.66044.2019102310461968476343384.0.0.0.dicom_BOLD_mb4_2mm_decision_run2_20191023100140_12_cHC1-7 (98x98x72x164)

Conversion required 12.768007 seconds (12.182047 for core code).

5

Oh also, my data came from a Siemens scanner, not Philips. Joining them with fslmerge seems like a good idea, though, at least in principle…but if possible it would be nice to make sure that there isn’t some other issue hiding in the data first.

6

@michaelcohen thanks for sharing your data. dcm2niix is correctly detecting that the CoilString (0051,100f) is not consistent across slices. This would be indicative of a situation where the user needs to intervene to determine what has happened. For example, would be consistent with a situation where the plug for one of the coils became disconnected in the middle of a series, catastrophically impacting the image. dcm2niix reports this in the command line:

Slices not stacked: coil varies

Inspecting your DICOM files shows that some slices require less disk space than others. Using a tool like dcmdump, gdcmdump or horos you can look at the slice headers. The larger files include the coil string:

(0051,100f) LO [HC1-7]

However, the smaller files are completely missing all the tags for private groups 0019 and 0051. However, all images preserve the private group 0029 which includes the crucial Siemens CSA header. I am going to go out on a limb here and infer that an anonymization script was applied to only some of these images. The script was smart enough to know that group 0029 should be preserved, but stripped out all other private groups. Unfortunately, this script was not applied to all the images, yielding variation in the coil string.

I think if you check the provenance of these images, you will find that dcm2niix works correctly with the images acquired by the scanner (if not, you need to work with your Siemens Research Collaboration Manager).

I think dcm2niix is justified in refusing to combine these images without human intervention. These redundancy checks are a feature, not a limitation of the tool. Your DICOM data is not of archival quality, and the source of the problem should be detected.

If you simply want to let dcm2niix proceed, you would want to remove the tag(s) that are conflicting/ For example:

gdcmanon --dumb --remove 0051,100f /path/to/DICOMS /path/output

7

Thanks! Your instructions worked well for cleaning up the files.

One other question: in trying to troubleshoot this, I’d like to examine the version of the same files that were never run through Flywheel to see if they have the same issue. (That is, did they appear to process cleanly before because I used a different version of DCM2NII/DCM2NIIX, or did Flywheel botch something?) How would I examine the problematic DICOM groups in other images?

8

Hi all

dcm2niix coverts my dicom files into one 4D volume.
How can I make it split into multiple 3D volumes?

9

Hi @makaros622, you can use fslsplit from FSL. Since this is a separate questions, please open a new thread for follow up questions.