New Enhanced DICOM format

Purpose

This page describes the new Siemens Enhanced DICOM format and how to properly convert it for postprocessing.

Introduction

With the advent of Numaris 10 (NX, in Siemens lingo) Siemens has stopped using the familiar mosaic DICOM format for primary data archive. Mosaics now include only very sparse information in the DICOM, and almost none of what is needed to use in modern data analysis pipelines. I don't have confirmation, but it seems like they are only produced for viewing on the host's inline viewer. Instead, Siemens now uses what they call an Enhanced DICOM. In that format, the pixel data are saved as a 4D matrix, and the header information is far more comprehensive. But, since both the pixel and header data formats have changed, it's likely that your legacy data processing tools will have problems.

Historical

With Numaris 4 (N4), Siemens introduced the mosaic DICOM format for functional and diffusion datasets. Before this, all images were stored slice-by-slice. So, a 500 measurement BOLD run with 60 slices would produce (500 x 60 =) 30,000 individual DICOM files. Each of those DICOMs needed to store identical patient info, scanner info, and a host of scan parameters. This is inefficient for hard drive and tape archive space. It also led to tremendous network burden when transferring the datasets. Each time a file is transferred, there is network overhead (handshakes, confirmations, etc.) that take time. This overhead is included for each and every DICOM, thus slowing down the transfer and clogging network bandwidth.

The mosaic format instead included all the pixel data for a volume (a timepoint for BOLD or diffusion direction for DWI) tiled "slicewise" in a single file. That file cut out a tremendous amount of redundant data storage since the header information was reduced by a factor of almost the number of slices. And, since many fewer files existed to be transferred over networks, it alleviated a lot of congestion. See this figure for a pictorial explanation:

The mosaic solution isn't perfect, of course. The format specification was never accepted by other manufacturers, so Siemens was alone in providing this format to its users, which led to more division amongst researchers eager to share data and processing tools & techniques. It also suffered from its own inefficiencies. The format specification required that the number of tiled slices be square (1, 4, 16, 32, 64, ...). If the acquisition didn't use a square number of slices, the tiled array would be up-sized to the next larger square number, and the space was padded with zeros, or, pure black images. For instance, in the figure above, the run had only 60 slices, so the mosaic included 4 blank slices to create a square tiled grid. Those blank images use the same amount of space as actual images, so some of the space savings might be given back if the number of slices was, say, 36. In that case, the mosaic DICOM would still need to have 64 images, but 28 of them would be nothing but zeros. Almost half the hard drive space dedicated to image storage was wasted. Additionally, the format specification does not permit slice-by-slice parameters. Although almost unheard of, images of this type need not be acquired with the same orientation. Nor does each slice need to be acquired with the same flip angle. In cases like those, the mosaic format could not be used at all because it could not save the individual slice parameters.

Format Changes

In order to resolve the vendor-specific data format inconsistency, improve efficiency, and allow for generalized parameter headers, Siemens decided to transition to using Enhanced DICOMs to store functional, DW, and ASL images. The Enhanced DICOM format is new to Siemens, but was first proposed in 2005 by the DICOM Standards Committee. Philips began supporting the format as an optional feature in 2008. At the time of writing it is still unclear if GE supports Enhanced DICOMs or not.(I'll update this post when I have firm information on that point.)  The Enhanced DICOM format saves slices in a 4D matrix. The 4th dimension is not generally used for functional, DW or ASL imaging, but is available for repeated measurements of the same type. As a consequence, the format will usually have this dimensionality:

nRE × nPE × 1 × nS

Where, nRE is the number of points in the read (or frequency) encode direction, nPE is the number of points in the phase encode direction, and nS is the number of slices. This format resolves the square number of slices issue from the mosaic format while keeping its single-header efficiency. Also, the Enhanced DICOM format allows for slice-by-slice acquisition headers, which is a general solution to parameter storage.

Why the Problems, Then?

So, if the Enhanced DICOM format has been around more than a decade, and Philips users have been using it for years, why are the conversion and analysis tools broken? That comes down to proprietary sections of the DICOM header. The DICOM standard provides relatively few enforced parameter tags (e.g. TR, TE, orientation, etc.). But, when you process fMRI data, for instance, you need many more parameters. Those need to be extracted from sections of the header that are not standard between vendors. These sections are variously called "shadow," "hidden," and "proprietary," and they all mean the same thing in this context. The legacy tools could parse that section of the header, where a comprehensive list of parameters are stored. Now that section is in a different place, and it has a slightly different format. So, the old tools would fail when trying to parse the headers. When the Siemens implementation of this format came with our Siemens Vida scanner, we had to work with some groups that curate the conversion tools to make sure all the parameters needed are correctly read and reported.

So, how do I convert the enhanced DICOM to NIfTI format?

At the time of writing, Chris Rorden's dcm2niix is the only conversion tool we are confident will work. We worked with Chris to independently validate all the parameters in a wide variety of use cases scenarios. These validations pass his QA tests and match our measured data. However, these changes only exist in v1.0.20181022 and later, so be sure you're up to date! Usually, the preferred method to get dcm2niix is as part of the MRIcroGL package. But, until the current stable release of MRIcroGL is updated to include the updates to dcm2niix, you will have to download and compile it from the GitHub link at the beginning of this paragraph.

Admonition Against the Use of Mosaics From NX Scanners (Like the Vida)

At the time of writing, there is no way to disable the creation of mosaic DICOMs for functional, DW, and ASL scans on the Siemens Vida scanner. But, the mosaics don't have much information in their headers, and almost none of what is needed to process data using mainstream pipelines. So, it is imperative that you not attempt to use them for scientific analysis. Note that this does NOT apply to the Siemens Skyra scanner. Mosaic DICOMs are the primary and MUCH preferred format to export data for that generation and virtually every other generation of operational Siemens MR scanner. Mosaic DICOMs are only problematic when they come from NX scanners, and at the time of writing, the Vida is the only NX-line scanner here at UT. But, there are several other Vida scanners in use already at other institutions, and the Siemens Sola (which is a 1.5T model) also produces these DICOMs.