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!

[Spenhouet]

@matthew-brett Is there any update on this?

[matthew-brett]

@Spenhouet - indeed there is - have a look over at https://nipy.discourse.group - and in particular the "DICOM" category. We are at the active planning stage.

[Spenhouet]

Hi @matthew-brett, seems since last time I checked in on this (1 year ago) there was nothing noteworthy new on the mentioned group with respect to DICOM.
Is there any news on when we can expect this as part of nibabel? Is the grant still open/active?
Would really appreciated an update and some insight on coordination, decision making and timelines.

[matthew-brett]

@Spenhouet - yes - sorry - the grant has been held back by my time, primarily. I will get back to you soon about our plans.

[Spenhouet]

Hi @matthew-brett,

I hope you're doing well. It's been another year since I last checked in on the progress of the DICOM to NIfTI implementation in nibabel. I truly appreciate the effort you and the team put into this.

I noticed that the group you previously referred to, https://nipy.discourse.group/, is no longer accessible. I'm curious about the current status of the project and whether the grant is still active.

[matthew-brett]

So sorry to be slow to reply here - I was trying to get some stuff done.

Just to say - I have just finished porting over the nipy.discourse.group stuff over to Github discussions:

• Neuroimaging data formats at
  https://github.com/orgs/open-dicom/discussions/categories/neuroimaging-data-formats
• DICOM conversion at
  https://github.com/orgs/open-dicom/discussions/categories/dicom
• Surface API at https://github.com/orgs/nipy/discussions/categories/surface-api

In answer to your question - yes the grant is still active, but as things stand it will finish at the end of September. The problem has been that I have a near-full-time job and it's been very hard to find time to work on the grant - but I will be doing a lot of work during this coming month. There has been some progress, but not enough, and not visible enough, to yet point you to it, but I will soon. If you'd like to discuss, we can make some time for a Zoom or similar. Tagging @ZviBaratz - in case you've got any thoughts?

[ZviBaratz]

My turn to apologize for the delayed response. Unfortunately, I haven't had much time to work on this either. I did try to give another quick sprint about five months ago, just to factorize the CSA header parsing functionality as an independent package (see csa_header). I think it was pretty much complete, but then integrating functional testing took more time than anticipated, fires started breaking on other fronts, and work halted there.

I think, in terms of the possibility to convert DICOM to NIfTI in a way that's comparable to dcm2niix, there's still a substantial way to go.

• I never managed to really get it off the ground, but I think one thing that's truly needed is a central reference for the expected results (my attempt to create a general outline is available as dicom-gallery). A Pythonic conversion tool absolutely should comply with dcm2niix's outputs—@neurolabusc has already done a monumental amount of work on this front, and IMO, diverging from the established format would be a mistake. There are (to date) 34 dcm_qa* repositories under @neurolabusc's account, which would certainly make a strong foundation.
• Different parts of dcmstack and dicom_parser (both abandoned) need to be either integrated into nibabel or rewritten as an independent package or packages.
• A suite of functional tests needs to be created to ensure the results comply with dcm2niix's results.

Hope this makes sense. I might be overcomplicating (or, possibly, oversimplifying), but I think this approach could really help standardize DICOM to NIfTI (and maybe other formats?) conversion efforts in Python and beyond.

[s-madhavan]

Hi everyone,

@Spenhouet I'm currently trying to convert DICOM to Nifti for Phillips scanner and am running into the following issue:

raise WrapperError("File contains more than one StackID. "

nibabel.nicom.dicomwrappers.WrapperError: File contains more than one StackID. Cannot handle multi-stack files
Finished subject YA-0690270L_20240313-20240313 1

I am using the latest version of Heudiconv to convert files heudiconv latest version is 1.1.1. Has this bug been fixed? I'm not seeing anything on here or on Neurostars?

For those that are running into the same issue how did you resolve it? Trying to get my DICOM .dcm files to Nifti BIDS format. If anyone has a script they could share that would be very helpful.

Thank you.

--Subbi M.

[Spenhouet]

@s-madhavan You should raise a new ticket and add a description and reproduction to that ticket. This ticket is not the right place for this.

[s-madhavan]

@s-madhavan You should raise a new ticket and add a description and reproduction to that ticket. This ticket is not the right place for this.

Hi. Thanks. Will do.

--Subbi M.