Convert DICOM to NIfTI with nibabel

[Spenhouet]

I would like to revive this feature request. It was already issued in 2015 here: #303
At the time dcmstack was recommended. It combined functions of nibabel to perform this conversion.

dcmstack is no longer maintained (as stated here) and already out-dated. For us it is already missing crucial features (like enhanced (multiframe) MR DICOMs or missing Philips headers) which forces us to switch to a temporary solution with dcm2niix (as proposed by nibabel here).

@moloney stated (also here) that this functionality will be added to nibabel.

This seems to be an effort done by @moloney, @matthew-brett, @effigies and @oesteban.
This effort might come into being via the CZI EOSS grant. See the grant application here.
The milestones outlined here mention that this functionality should be available 3 months after the grant starts which is January 1, 2021. Not sure if it is reasonable to expect the functionality to be released in nibabel around April 2021?

I would like to have this feature request issue open to track the state of this effort / project.
We would love to have this functionality since it allows us to perform everything in-memory instead of saving conversions to disk as necessary with the dcm2niix solution.

[matthew-brett]

Well done for finding the grant application! We're still finalizing start date - but yes - the plan is to get this done after by 3 months after the start date. We'll get back to y'all soon on the list when it's clear what the start date will be.

[matthew-brett]

By the way, @moloney was also part of the grant discussions, it's just he couldn't easily accept funding with the grant. We are still planning to work closely with Brendan on the dcmstack port.

[neurolabusc]

You may want to evaluate dicom2nifti. If your remit includes compressed transfer syntaxes, you will need to include some C libraries - dicom2nifti uses gdcmconv for those images.

I have a repository of enhanced DICOMs for validation. I also have some much larger enhanced datasets I can share with you if needed.

An alternative might be to adapt dcm2niix to support your needs. Both MRIcroGL and FSLeyes query dcm2niix to convert specific series from large datasets. If you want to skip saving to disk, you can have dcm2niix pipe image data direct to memory. dcm2niix already pipes uncompressed image data directly for pigz, so the tools are already available.

[jond01]

Hi, I just wanted to let you know about the medio python package where we handle dicoms (also multiframes) and niftis. We use there pydicom, itk and dicom-numpy for dicoms and nibabel (of course) for niftis. I guess you will find some of medio's functionalities useful.

I would like to help in nibabel's dicom effort! Is there a main issue/plan for this?

[matthew-brett]

Thanks for the comments - it would be great to have help. My own preference is for making the DICOM analysis be in Python as far as is practical, and to avoid big dependencies - if possible. I would like to make sure we have as much as possible in Python so that it's more obvious how to modify the code to new DICOMs, and therefore, to contribute.

I am sure you're right Chris, that we'll need C libraries for some of the low-level reads. I hope we can keep these to optional dependencies. Your datasets will be very useful - thanks very much for making them available.

If DICOM conversion code is already available in Python, and it's easy to read and adapt, and to install via pip etc, then there's no requirement it go in Nibabel - as long as we all know where we can contribute.

Thanks @jond01 for pointing us to Medio - I hope that I / we will soon have time to look at what we need to do, and start issues, collaborations, and so on. The grant hasn't started yet, because we've had to negotiate about moving the funding between organizations. I will get back to y'all soon, when we know more.

[neurolabusc]

Great. A nice aspect of starting with a clean sheet is that you can architect the code for modern DICOMs, including the enhanced format images. This can provide a much cleaner solution than kludging code developed before these were available. Another unusual feature you may want to keep in mind from inception is the renumbering of Private Data Element Tags. The stated intention of this property was the elimination of conflicts in Private Data Element Tags. However, the implementation of this in dcm4che and Agfa PACS actually generates conflicts where they did not previously exist. Concrete examples of this unintuitive behavior are provided here

• dcm_qa_agfa

Fortunately, pydicom has a method to handle this situation. As long as you support this feature from the start, you should not have any issues.

[maxrohleder]

Hey there! I am also really interested in the dicom2nifti feature.

I tested the nibabel.nicom.dicomwrappers.MultiframeWrapper class on Enhanced CT DICOMs from Siemens and I believe there is a conceptional mistake in the calculation of the affine matrices. I suspect this is because the affine is constructed following the approach for single frame dicoms from here instead of the multi frame formulation.

In theory, both approaches should yield the same approach, but the calculation of the slice normal is susceptible to the ij vs ji confusion of the dicom standard discussed here.

Are there any updates on the above mentioned grant and the resulting work?

I could offer to assist on this topic with the goal to get a vendor-unspecific loader for dicoms!
Cheers,
Max

[neurolabusc]

@maxrohleder can you share some sample enhanced CT DICOMs? I would like to add some to my open source validation repository of enhanced DICOMs . Currently, I have MRI data from Philips, Siemens and Canon. However, I have never seen enhanced CT data. One particular issue with CT is gantry tilt (e.g. see here for examples). This presents an issue for many tools (e.g VTK assumes rectangular volumes), but also a challenge for conversion. It would be useful to see two series of enhanced DICOM CT data: one without gantry tilt (creating a rectangular volume) and one with gantry tilt (resulting in a sheared volume). In theory, gantry tilt should be encoded in the NIfTI S-Form (the Q-Form can not represent shears).

[maxrohleder]

Hello @neurolabusc, I am predominantly working with data from the Siemens Cios Spin System, which is a 3d-enabled C-Arm mainly used in the surgical suite. The nature of this system implicates all sorts of extra parameters which need to be stored in the DICOM header. If you still want one of these datasets, I can maybe provide you a scan.

[neurolabusc]

@maxrohleder I would like to see a dataset. Ideally, one you can share publicly. Feel free to send a Dropbox / GoogleDrive link to the email address listed in my avatar.

[maxrohleder]

@neurolabusc Ill see what I can do!