# DICOM multiframe support
**URL:** https://discourse.slicer.org/t/dicom-multiframe-support/4806
**Category:** Development
**Tags:** dicom
**Created:** [November 19, 2018, 3:58pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806 "2018-11-19T15:58:30Z")
**Posts on this page:** 4
**Page:** 2
### Author:  [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [November 21, 2018, 3:20pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/29 "2018-11-21T15:20:12Z")
@Mihail_Isakov I do not have any experience with or access to the tool you are using, or to its source code, and I didn’t investigate the content of those files. All I know is that if I use established open source tools that I trust, I do not see inconsistency in how images show up in Slicer. I would be very surprised if dcm2niix didn’t sort frames, and that’s what I used to load the multiframe image into Slicer.
I won’t have time to debug this any time soon. But I also won’t take a screenshot from an unknown tool as a proof that data encoding by David Clunie is incorrect
---
### Author:  [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [November 21, 2018, 4:02pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/31 "2018-11-21T16:02:03Z")
As explained in the link mentioned in the first post of this topic, Slicer is not able to properly load this multiframe directly. I used dcm2niix to make a NIfTI first, which I then loaded into Slicer. The whole reason this topic started is because Slicer cannot (at least, not always) directly and correctly load multiframe DICOM images.
---
### Author:  [@Chris\_Rorden](https://discourse.slicer.org/u/Chris_Rorden)
#### Post date: [January 3, 2019, 10:49pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/33 "2019-01-03T22:49:38Z")
The latest development version of [dcm2niix allows programs like Slicer to request files for conversion](https://github.com/rordenlab/dcm2niix/issues/252). In addition, dcm2niix could also be extended to create NRRD files instead of NIfTI files. In my experience, DWIconvert is typically very robust. However, for situations like multi-frame it might be nice to have an alternative mechanism.
The simplest NRRD implementation would be to convert files very similar to NIfTI: with space being stored in the first three dimensions and the fourth used for time (fMRI) or diffusion direction (DWI). The gradient direction in NRRD seems a bit simpler than the FSL bvecs, so it seems that would be more direct.
This would take a bit of development effort, so if the Slicer community is happy with just using dcm2niix for NIfTI, I can understand.
---
### Author:  [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [January 3, 2019, 11:09pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/34 "2019-01-03T23:09:08Z")
@Chris_Rorden thank you for the followup, and for adding the feature!
I think @ihnorton @ljod @hjmjohnson are the right people to contribute their input on this topic.
[Previous page](https://discourse.slicer.org/t/dicom-multiframe-support/4806.md?page=1)