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 and XA31A.
With the advent of Numaris 10 (NX, in Siemens lingo) Siemens has stopped using the familiar mosaic DICOM format for primary data archive. Mosaics were only generated in XA10A and 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 at all. Instead, Siemens now uses the more standardized 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.
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 was extremely inefficient with respect to 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 DICOM was created to alleviate some of these problems. It includes all the pixel data for 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, who maintains the DICOM standard. 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, 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 tiles use the same amount of space as actual images, so some of the space savings will 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. 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.
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. 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 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 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 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 properlyand 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 (Like the Vida)
Although it is no longer supported, you might come across mosaic DICOMs that were generated on XA10A scanner. 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 did, 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.