Purpose
This is an updated post I originally wrote in 2018 while at the University of Texas at Austin. That post has grown stale with outdated references, instructions, and advice, so it was time for a glow up. What follows should be applicable for XA30A, XA31A, XA50A, and XA51A.
Introduction
With the advent of Numaris 10 (NX, in Siemens lingo) Siemens stopped using the venerable and familiar mosaic DICOM format for primary data archive. On X-line scanners (XA) mosaics were only generated in version XA10A and they included 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 were only produced for viewing on the host’s inline viewer. XA10A was an intermediate release, and with starting with XA11A, mosaic DICOMs have been removed and no longer supported or even generated at all. Instead, Siemens now uses the more standardized Enhanced DICOM format. In that format, the pixel data are saved as a multi-frame matrix, and the header information is far more comprehensive. But, since both the pixel and header data formats have changed, it is likely that your legacy data processing tools that were designed for mosaic DICOMs will have problems.
Historical
With Numaris 4 (N4), Siemens introduced the mosaic DICOM format for functional and diffusion datasets. Before this, virtually 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. This was tremendously inefficient because each of those DICOM files needed to store identical patient info, scanner info, and a host of scan parameters. This this repetitive storage of data wasted hard drive and tape archive space. This is especially true since it is not uncommon for the header section of a single image DICOM to take up more space than the image itself, and almost all of that was completely unnecessary to repeat. 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 when 30,000 files have to be transferred (or, “pushed” in DICOM terminology).
The mosaic DICOM was created to alleviate some of these problems. It includes all the pixel data for all the slices of a volume (i.e. a timepoint for BOLD or diffusion direction for DWI) tiled “slicewise” into a single image and stored 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. It has its own peccadillos. The format specification was never accepted by other manufacturers or NEMA, the organization that maintains the DICOM specification. As a result, 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 a square number of tiled slices (1, 4, 16, 32, 64, etc.). 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, that is, 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 tiles use the same amount of space as actual acquired images, so some of the space savings will be given back if the number of slices was, say, 36. In that hypothetical 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 pixel data storage is wasted. Additionally, the format specification does not permit slice-by-slice parameters. This made slice timing and other slice-specific information impossible to store in standard tags. Furthermore, 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. This is one of the biggest reasons mosaic formatted DICOMs were only used for BOLD and DWI (and some other niche applications). It was not intended to be used for anatomical imaging, and clinical images (again, except for a few rare applications) almost never used them.
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, ASL, and most other multi-frame images (which is the bulk of all imaging on MRI scanners). In fact, it is possible to use this feature for all DICOMs, and realize its benefits. 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 multi-frame matrix. For functional, DW, and ASL applications, there is a non-functional 4th dimension (but that dimension is available for repeated measurements of the same type). As a consequence, the format will usually have this dimensionality in MATLAB and some other tools:
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 the way I use them, 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, some old tools might not work properly and would fail when trying to parse the headers. When the Siemens implementation of this format came with the Siemens Vida scanner at UT Austin, I worked 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 I am confident will work reliably. I 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
Although it is no longer supported, you might come across mosaic DICOMs that were generated on a scanner that ran XA10A for a short time. There was no way to disable the creation of mosaic DICOMs for functional, DW, and ASL scans on those scanners, so there are lot of them floating around. But, the XA10A 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 scanners using the VB, VD, or VE lines. Mosaics created on those scanners still conform to the specifications they always have, and are acceptable to use in any application. 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-line scanners.
My X-line Scanner Still Pushes Single Image DICOMs
You may be reading this because you searched for information on why your X-line scanner (running XA20, XA30, XA31, XA50, or XA51) is sending tens of thousands of files to your PACS. This can and does frequently happen. The reason is that many clinical PACS systems do not support the SOP classes used by Enhanced DICOMs. In other words, PACS systems that don’t know about the newest Enhanced DICOM formats simply discard them immediately after receiving them. In order to support those PACS systems, Siemens provides what they Interoperability DICOMs. This is essentially the pre-mosaic format, where DICOMS store one and only one image with the redundant headers and all the other problems mosaic and Enhanced formats were designed to fix. Yes, this is a huge pain for researchers, but since all PACS systems support these files, there is no chance for data loss due to incompatibility. If your scanner is pushing DICOMs like this, it is because it is configured to “push” DICOMS to your image archive server (or PACS) Interoperability DICOMs. If that’s true, then you should fist check if your server/PACS supports Enhanced DICOMs. If it does, then you can simply ask your friendly Siemens field service engineer (or call the UpTime Center at 800-888-SIEM) to change the configuration. If your server can’t accept Enhanced DICOMs, there are limited options, and they are all too complicated to discuss here; it’s beyond the scope of this post. Feel free to contact me if you need advice on making this work.