NIfTI‐MRS: A standard data format for magnetic resonance spectroscopy

Abstract

Purpose

Multiple data formats in the MRS community currently hinder data sharing and integration. NIfTI‐MRS is proposed as a standard spectroscopy data format, implemented as an extension to the Neuroimaging informatics technology initiative (NIfTI) format. This standardized format can facilitate data sharing and algorithm development as well as ease integration of MRS analysis alongside other imaging modalities.

Methods

A file format using the NIfTI header extension framework incorporates essential spectroscopic metadata and additional encoding dimensions. A detailed description of the specification is provided. An open‐source command‐line conversion program is implemented to convert single‐voxel and spectroscopic imaging data to NIfTI‐MRS. Visualization of data in NIfTI‐MRS is provided by development of a dedicated plugin for FSLeyes, the FMRIB Software Library (FSL) image viewer.

Results

Online documentation and 10 example datasets in the proposed format are provided. Code examples of NIfTI‐MRS readers are implemented in common programming languages. Conversion software, spec2nii, currently converts 14 formats where data is stored in image‐space to NIfTI‐MRS, including Digital Imaging and Communications in Medicine (DICOM) and vendor proprietary formats.

Conclusion

NIfTI‐MRS aims to solve issues arising from multiple data formats being used in the MRS community. Through a single conversion point, processing and analysis of MRS data are simplified, thereby lowering the barrier to use of MRS. Furthermore, it can serve as the basis for open data sharing, collaboration, and interoperability of analysis programs. Greater standardization and harmonization become possible. By aligning with the dominant format in neuroimaging, NIfTI‐MRS enables the use of mature tools present in the imaging community, demonstrated in this work by using a dedicated imaging tool, FSLeyes, for visualization.

Short abstract

Click here for author‐reader discussions

1. INTRODUCTION

MRS is a highly flexible technique that can generate a wide range of sensitive and specific imaging contrasts complementary to the typically water‐derived contrasts of MRI. MRS allows simultaneous measurement of multiple in vivo metabolite concentrations that, when combined with additional dynamic contrast‐encoding techniques, can be used to derive metabolite concentration time courses, metabolite diffusion properties, or in vivo chemical kinetics. ¹ , ² , ³

In vivo MRS data typically requires a complex data storage array containing multiple dimensions, including spectral frequency (equivalently encoded as a time dimension), spatial encoding, and any dimensions required for “dynamic” encoding. Before preprocessing, additional array dimensions may be required, for example, to separately store signals from multi‐channel receive coils, or multiple transients. ⁴ In addition, any information about the acquisition that is required for interpretation needs to be stored, too, including the transmitter frequency and the signal dwell time, as well as information on the spatial dimensions and orientation of the measurement volume.

To date, there is no established standardized data format for communicating MRS and MRSI data. Whereas a Digital Imaging and Communiations in Medicine (DICOM) standard for MRS(I) exists, ⁵ it is not fully implemented by the vendors. Crucially, DICOM does not provide an intuitive way to store spectroscopic data or a standardized method to encode data that requires two or more additional encoding dimensions. As a result, vendors have developed their own separate, proprietary (closed) formats to store raw and processed spectroscopic data. The specific format used is dependent on the scanner software version and local practice. These proprietary formats vary greatly in the degree in which data has been subjected to inline processing, that is, whether data has been spatially reconstructed, which (and how) metadata is stored, and how the storage is formatted.

The lack of a standard data format hinders the use of MRS in several ways:

1. It impedes integration with other imaging modalities.

   Without standardized encoding of spatial orientation and position, registration with other modalities requires a per‐data‐format solution. This hinders both co‐analysis of spectroscopic data with other modalities, and leveraging of other modalities in reconstruction and processing of the typically low‐signal MRS.

2. It impedes the consistent analysis of data.

   Any spectroscopic analysis program must implement dedicated interpretation modules for each format. Development of new modules is time consuming and relies on expert knowledge of a format. This results in incomplete coverage of the formats by any one analysis pipeline. Thus, consistent (and comparable) analysis is prevented.

3. It impedes the creation of new, discrete, specialized tools.

   Without a standard storage format, processing and analysis of spectroscopic data often occurs in a single monolithic process, frequently relying on local analysis pipelines and depending on the local MRS expert to create them. This impedes modular processing, which is important for development and uptake of new acquisition and analysis methods, as well as improving existing ones. The barrier to creating new tools is high if implementation of all processing steps is required. Furthermore, quantifying improvements from modifying a discrete step is difficult if it is inseparable from other steps.

4. It raises the difficulty of sharing data.

   Compared to other modalities, sharing MRS data is not straightforward. With the diversity of storage formats, especially across platforms, users cannot reliably read and interpret data received from other users. Data‐sharing repositories are required to handle mixed data types, which are processed to varying levels and have varying metadata. This creates enormous sharing friction and discourages researchers from sharing. Anonymization tools required for ethical public sharing of data require per‐format implementation.

Combined, these factors significantly raise the barrier to adoption and use of MRS, especially for nonexpert users. Compared to other MRI modalities, MRS analysis workflows remain highly customized and specific and require unique MRS expertise on site.

To address these issues, we propose a single data format based on the Neuroimaging Informatics Technology Initiative (NIfTI) format ⁶ for storing single‐voxel, spectroscopic imaging, and unlocalized spectral data. We call the proposed format NIfTI‐MRS. The NIfTI file format is the standard format for storing anatomical, functional, diffusion, and quantitative MRI and arterial spin labeling data in the MR neuroimaging research domain. NIfTI has provided a cornerstone for analysis across neuroimaging, allowing integrated analysis of modalities.

The proposed format will:

• provide a simplified pathway from scanner to final analysis;

• enable interoperability and modularity of analysis programs;

• enable easier display and co‐interpretation with other modalities, and

• establish a format for data sharing.

In addition, the proposed format is designed to provide a simple anonymization procedure and flexible storage of meta‐data, further removing friction from the process of sharing.

To facilitate adoption, this work describes the implementation of an open‐source command‐line conversion program capable of converting many original formats to the proposed format. The program, spec2nii, provides single‐point conversion for all spatially reconstructed data (including single‐voxel data) from 14 different formats alongside anonymization scripts and manual editing tools for NIfTI‐MRS.

By aligning MRS with the most widely used neuroimaging format, NIfTI‐MRS will also allow researchers to create comprehensive MRS research designs that incorporate different modalities with ease. To demonstrate this, we have created an FSLeyes (FMRIB Software Library, University of Oxford, Oxford, UK) ⁷ plugin to visualize multi‐dimensional NIfTI‐MRS data alongside structural MRI and results from MRS fitting.

2. METHODS

2.1. The NIfTI‐MRS data format

A brief description of the proposed standard (version 0.6) is included here. The full standard is provided as Supporting Information, and the latest version can be found in Ref. 8.

2.1.1. Design

The NIfTI‐MRS format is designed to contain single‐voxel, contiguous multi‐voxel, and unlocalized (or partially localized) time‐domain MRS data in up to three spatial dimensions (i.e., MRSI‐encoded data). Optionally, NIfTI‐MRS can encode up to three additional data dimensions, for example, for arrays of interrelated signals. The standard is designed with low minimum‐conformance metadata requirements to simplify adoption, while providing for more complicated metadata requirements in the full format.

The NIfTI format contains three sections: the data header, optional header extensions, and the data block. The proposed NIfTI‐MRS format comprises a NIfTI‐2‐formatted file with a mandatory header extension formatted according to the JavaScript Object Notation (JSON) standard. ⁹ , ¹⁰

In NIfTI‐MRS (Figure 1), the NIfTI data header ¹¹ , ¹² structure is identical to the one used for structural or functional MRI data, although some values are constrained or re‐utilized for spectroscopy‐specific purposes. For example, the dwell time of the time domain data is stored in pixdim ⁴ (with units are specified in the xyzt_units field). Spatial position encoding, that is, dimensions and orientation of the measurement volume, is implemented as in the NIfTI specification, and a default value of pixdim is specified for unlocalized data. Finally, only complex datatypes may be specified in the datatype field (e.g., “DT_COMPLEX”, 32). The NIfTI‐MRS standard is versioned, and the version is specified in the intent_name field (in the format mrs_v{major}_{minor}).

FIGURE 1.

Schematic representation of the proposed NIfTI‐MRS format. The format utilizes the native NIfTI header and data block, whereas using a JSON‐formatted NIfTI header extension to store additional required metadata. The NIfTI data block encodes spatial dimensions (dimensions 1–3), a time domain (dimension 4), and up to three further dimensions (total limited to seven by the NIfTI format definition). By default, the additional dimensions encode uncombined receive coil information (dimension 5), repeated measurements (dimension 6), and an “indirect” frequency dimension, that is, for 2D‐NMR (dimension 7). The purpose of these dimensions can be explicitly coded and changed by using the “dim_…” keys in the header extension. JSON, JavaScript object notation.

The NIfTI‐MRS data block is used to store up to 7D complex time‐domain data. The first four dimensions are required for a valid NIfTI‐MRS file: the first three dimensions are used for spatial encoding (x, y, and z coordinates), and the fourth dimension is used to store the time‐domain FID (or echo). All three spatial dimensions have a size of one for single‐voxel data. The NIfTI(‐MRS) format is only suitable to store spatially reconstructed data; that is, data that has been reconstructed from the acquired k(t)‐space representation. The remaining three dimensions (fifth, sixth, and seventh) are optional. They flexibly encode different dynamic aspects, with the specific purpose and interpretation of each dimension being documented in the header extension. NIfTI‐MRS is limited to seven dimensions by the definition of the parent NIfTI format. Modification of the data storage format to extend the number of dimensions would break compatibility with existing imaging software tools.

The header extension has the official NIfTI identification code 44, “NIFTI_ECODE_MRS.” It comprises key‐value pairs formatted according to the JSON standard, which can be arbitrarily nested, if necessary. The header extension contains the minimum necessary metadata required for meaningful interpretation of the spectroscopic data, additional information about the optional higher encoding dimensions, and further MRS‐specific metadata.

2.1.2. Header extension metadata

The header extension contains 4 types of metadata key:

1. The two mandatory keys SpectrometerFrequency and ResonantNucleus. These must be present in all NIfTI‐MRS formatted files because they are a necessary requirement for correct reconstruction and interpretation of the time‐domain data.

2. Higher encoding dimension information. Three keys are defined per additional encoding dimension (n = 5, 6, 7): dim_{n}, dim_{n}_info, and dim_{n}_header. The first, dim_{n}, is mandatory if the dimension is used. Dim_{n} takes the value of a list of predefined tags (e.g., DIM_COIL or DIM_EDIT) to identify the purpose of the dimension. A DIM_USER_{0–2} tag allows for user‐specified purposes, which can be described using the dim_{n}_info field. The dim_{n}_header tag enables each element of a dimension to be associated with different values of metadata keys.

3. Standard‐defined metadata. These keys correspond to well‐defined and frequently used sequence, hardware, or subject data. They are defined in the NIfTI‐MRS standard and may not be redefined. These keys are optional.

4. User‐defined metadata. Keys can be arbitrarily defined by users to store unusual metadata not foreseen in the standard or for which no fixed format or recommendations exist. User‐defined JSON metadata permits additional fields for user‐defined keys, encouraging in‐place documentation to aid interpretation of the keys. These keys are optional.

2.1.3. Spatial information

Orientation, position, and voxel size information are stored in the NIfTI‐MRS header in accordance with the NIfTI standard. NIfTI encodes the spatial information using one, or both, of two (4 × 4) affine matrices: qform and sform. The former is stored using a series of header keys (pixdim, quatern_b, quatern_c, quatern_d, qoffset_x, qoffset_y, qoffset_z, qfac), whereas the latter is stored directly. These t affine matrices each encode the relationship between the data stored in the 3D spatial grid and a meaningful coordinate system. The most common coordinate system is that of scanner–anatomical ({qs}form_code = 1), that is, relative to the position of the subject in the scanner; however, it can also be relative to just the physical scanner, the scanner table, or a defined standard interpretation space ({qs}form_code = 4), for example, “MNI_152.” ¹³ Two different coordinate systems can be encoded by using each affine matrix. NIfTI‐MRS follows the original NIfTI standard and emphasizes the use of qform as the default.

As such, for NIfTI‐MRS, conformance is achieved in the header either when:

1. qform_code is set >0,

2. The second to fourth elements of pixdim are set to the appropriate voxel dimensions, or to a default of 10 m,

3. quatern_b, quatern_c, quatern_d, qoffset_x, qoffset_y, qoffset_z are set,

4. A valid value of qfac is set.

Or:

1. qform_code is set = 0 (NIfTI_XFORM_UNKNOWN),

2. The second to fourth elements of pixdim are set to the appropriate voxel dimensions or to a default of 10 m.

The former pixdim option is suitable for data that has a meaningful spatial position, and the latter for data with no real‐world position, for example, simulated data. Use of the default pixdim size (10 m) indicates a dimension has no unlocalization, or that it has poorly defined extent (e.g., unlocalization provided only by the limited extent of coil sensitivity).

The NIfTI format in general (and therefore also NIfTI‐MRS) cannot store spatially noncontiguous data (i.e., data with a gap between voxels or slices) in a single file. Distinct contiguous volumes need to be stored separately.

2.1.4. Anonymization of protected health information

To ease the process of anonymization, all standard‐defined metadata keys are marked as privacy‐sensitive or not privacy‐sensitive in the standard. User‐defined metadata may be self‐marked as privacy‐sensitive by appending “private_” to the start of the key or any nested key within the definition.

Anonymization of data stored as NIfTI‐MRS is simplified through two features:

1. Only a subset of metadata is retained in the conversion to NIfTI‐MRS. This metadata is selected and only incorporates that which is well defined.

2. Anonymization tools acting on NIfTI‐MRS can reliably identify sensitive fields that have been converted using their definition in the standard.

2.1.5. Processing provenance

Preprocessing steps applied to the data can be optionally recorded in the header extension. The type of preprocessing applied, the program used, the program version, and any additional information provided by the preprocessing algorithm can be stored sequentially in the “ProcessingApplied” field. Provenance is not provided by the NIfTI‐MRS data standard itself but either requires adequate implementation in relevant software packages or manual addition by users.

2.1.6. Phase and frequency conventions

The NIfTI‐MRS standard defines a strict frequency and phase convention for data. This convention follows the conventions of Levitt. ¹⁴ In this convention, the absolute frequency scale should increase from left to right. For nuclei with a gyromagnetic ratio greater than zero, this corresponds to resonances from nuclei with less shielding (more deshielding), which therefore experience a higher magnetic field, appearing on the left; that is, they have more negative (higher magnitude) Larmor frequencies, noting $\omega =-\gamma B_0$. This results in a typically displayed chemical shift (“ppm”) axis increasing from right to left. A description of this convention in the spectral time domain is provided in the specification.

2.2. Software implementation

To promote the use of NIfTI‐MRS, the standard has been implemented into software for conversion, visualization, and data input–output (I/O). Functions for loading, writing, and visualizing NIfTI‐MRS data have been created for common programming languages and integrated into open‐source analysis packages.

2.2.1. Conversion to NIfTI‐MRS

An open‐source conversion program spec2nii has been created. Spec2nii reads vendor‐proprietary, DICOM, and processing toolbox formats and generates NIfTI‐MRS‐formatted files. The program can also inspect, edit, and anonymize existing NIfTI‐MRS files. The program operates on the command line; is written in Python; and is developed as a public, open‐source resource

2.2.2. Visualization using FSLeyes

To enable visualization of the multi‐dimension NIfTI‐MRS format, an FSLeyes plugin has been created. FSLeyes is the free, open‐source FMRIB Software Library (FSL) image viewer. The developed plugin extends FSLeyes to interpret the NIfTI‐MRS format and enables display of single and multi‐voxel spectroscopy stored in the format.

3. RESULTS

3.1. The NIfTI‐MRS data format

The specification for the NIfTI‐MRS data format is available with this document as Supporting Information and online at Ref. 8. To assist in the interpretation of the standard, both online explanatory documentation (wtclarke.github.io/mrs_nifti_standard/) and example data ¹⁵ have been created. Figure 2 shows extracts of NIfTI‐MRS header extensions from 4 of the 10 example datasets. These four examples demonstrate the structure of the header extension, the flagging of privacy‐sensitive data, dynamic header values describing different conditions in one of the additional data dimensions (here spectral editing), and records of processing provenance. Additional examples are given in the specification and in the example data (at Ref. 15), including an example of “Fingerprinting” (example_09.nii.gz) where four different changing acquisition parameters would exceed the number of available data dimensions and do not form a densely filled rectilinear grid. In this case, a single additional dimension (dimension 5) is used, and arrays of each changing parameter are stored in the dim_5_header field.

FIGURE 2.

Extracts of NIfTI‐MRS JSON‐formatted header extensions for 4 different pieces of example data. The full example data is available from Ref.15. Each example demonstrates a different aspect of the header extension format. Figure annotations are shown as blue italicized text. (A) Structure of a header extension of ¹H single‐voxel data before preprocessing. (B) Header extension for processed ³¹P MRSI, including fields that are marked for anonymization (red). (C) Example of dynamic header fields indicating an editing condition stored in the seventh dimension. (D) Extract of the processing provenance in a MEGA‐PRESS ¹⁶ sequence preprocessed using FSL‐MRS ¹⁷ . ¹H, hydrogen‐1; ³¹P, phosphorus‐31; FSL, FMRIB Software Library; MEGA‐PRESS, Mescher‐Garwood point resolved spectroscopy.

3.2. Software implementation

3.2.1. Conversion to NIfTI‐MRS

The conversion program spec2nii has been created and released as a Python package. The package is developed online (https://github.com/wtclarke/spec2nii) and is available from the PyPI and Conda package managers. Spec2nii provides automatic or semi‐automatic conversion of 14 data formats (vendor‐proprietary and DICOM) to NIfTI‐MRS (Table 1).

TABLE 1.

List of spec2nii supported formats in version 0.3.4

			Spectroscopy Formats Handled
Vendor/ Software	Format	File Extension	SVS	MRSI	FID	Automatic Orientation	Notes
Siemens	Twix	.dat	✓	×	✓	✓	VB and VE baselines
Siemens	DICOM	.ima	✓	✓	✓	✓
Philips	SPAR/SDAT	.SPAR/.SDAT	✓	×	✓	✓
Philips	data‐list	.data/.list	✓	×	✓	✓
Philips	DICOM	.dcm	✓	×	✓	WIP
GE	pfile	.7	✓	✓	✓	✓	Per‐sequence mapping required
UIH	DICOM	.dcm	✓	✓	✓	✓
Bruker	2dseq	–	✓	✓	✓	✓	PV 5.1, 6.0, 6.0.1, 7.0.0, 360
Bruker	fid	–	✓	×	✓	WIP	PV 5.1, 6.0, 6.0.1, 7.0.0, 360
Varian	fid	–	✓	×	✓	WIP
LCModel	RAW/H2O	.RAW/.H2O	✓	×	✓	×
jMRUI	Text	.txt	✓	×	✓	×
jMRUI	MRUI	.mrui	✓	×	✓	×
–	ASCII	.txt	✓	×	✓	×

✓ = included fully; FID, free induction decay; WIP = work in progress, X = not yet included (inclusion dependent on the availability of test data and information on interpretation of the data‐format). SVS, single voxel spectroscopy

Figure 3 outlines the proposed use cases of spec2nii and NIfTI‐MRS enabled by this work:

1. Varied input data is passed to spec2nii.

2. spec2nii identifies the appropriate reconstruction and conversion pathway.

3. Conversion is carried out, and a NIfTI‐MRS file is returned.

4. Preprocessing is carried out using NIfTI‐MRS as an intermediary format.

5. Preprocessed data is stored or further analyzed (fitted).

FIGURE 3.

Proposed MRS and MRSI processing pipelines using NIfTI‐MRS and incorporating conversion in spec2nii. In the proposed pipeline, raw data from a variety of formats (e.g., DICOM, Siemens “Twix.dat”, GE “p‐file,” or Philips “SDAT/SPAR”) are converted to NIfTI‐MRS using spec2nii. Subsequently preprocessing can be applied, with both the input and results stored in NIfTI‐MRS. Data can be shared with other users or a data repository in a format‐agnostic way at any stage of the preprocessing pipeline. The preprocessed NIfTI‐MRS file can then be passed on to modeling software. Spec2nii can convert unlocalized, single‐voxel, and spatially reconstructed MRSI. In the future, spec2nii will also convert MRSI stored in k‐space for certain common supported sequences. For other sequences (e.g., those with non‐Cartesian trajectories), a pipeline incorporating the ISMRMRD format ¹⁸ and third‐party reconstruction is proposed. The red box indicates software yet to be implemented. DICOM, Digital Imaging and Communications in Medicine.

The data at any stage after conversion (stage 3) can be shared, whether that is the unprocessed converted data, fully preprocessed, or partially processed data.

For this work, only the conversion of spatially reconstructed data has been implemented in spec2nii. Data that are stored in a k‐space representation cannot currently be converted. In the future, some spatially unreconstructed data from standard vendor‐supplied MRSI sequences will be handled by spec2nii. For data requiring specialist reconstruction, for example, those with non‐Cartesian trajectories, we propose a future pathway incorporating conversion to International Society for Magnetic Resonance in Medicine raw data format (ISMRMRD) ¹⁸ and third‐party reconstruction provided by the sequence developers. To ease use of NIfTI‐MRS with custom or “offline” reconstruction routines, we have provided minimal code examples of NIfTI‐MRS input/output (I/O) (see next section), which could be used to output NIfTI‐MRS directly.

The formats supported by spec2nii are summarized in Table 1. Spec2nii carries out automatic spatial orientation calculations for 7 of the 14 supported formats.

3.2.2. NIfTI‐MRS I/O and compatibility

In Ref.19, minimal examples of NIfTI‐MRS file readers have been provided in 4 common programming languages (Java, MatLab [MathWorks, Natick, MA], Python, and R). The examples exploit the availability of robust NIfTI I/O libraries in those programming languages.

Support for NIfTI‐MRS has been established in five open‐source spectroscopy analysis packages: FSL‐MRS, ¹⁷ Osprey, ²⁰ Spant, ²¹ , ²² Vespa ²³ (https://github.com/vespa‐mrs/vespa), and FID‐A. ²⁴ Each package has I/O compatibility with the standard. Example short‐TE STEAM and water reference data at 7 tesla, provided in the NIfTI‐MRS format and processed in FSL‐MRS, Spant, and Osprey (with Osprey using FID‐A as foundation), are shown in Figure 4. The spatial location of the single voxel is shown overlaid on a NIfTI structural image in each package. This demonstrates the benefit for interoperability of different software solutions, and the potential to form the foundation of a mutually compatible, multi‐language analysis software ecosystem.

FIGURE 4.

NIfTI‐MRS single voxel spectroscopy data processed in 3 spectroscopy toolboxes supporting input and output of NIfTI‐MRS data. (A) Raw data converted to NIfTI‐MRS format by spec2nii was loaded and preprocessed in each of the toolboxes before being written back out to NIfTI‐MRS. Comparison of water‐suppressed (B) and water‐reference (C) data processed in each toolbox is simple using the pipeline in (A). The output NIfTI‐MRS data is easy to present alongside structural data stored in NIfTI format using a variety of MRS analysis software (D)

3.2.3. Visualization in FSLeyes

Visualization of NIfTI‐MRS‐formatted data is possible using FSLeyes and the NIfTI‐MRS plugin for FSLeyes. The plugin implements:

• a pannable and zoomable display for spectra;

• display of NIfTI‐MRS headers;

• automatic calculation of the chemical shift axis;

• display of individual spectra stored in the higher dimensions (5th–7th dimensions);

• interactive zeroth and first‐order phasing of spectra, and

• easy comparison of spectra from different voxels.

The plugin is maintained at https://git.fmrib.ox.ac.uk/wclarke/fsleyes‐plugin‐mrs and is available from the Pypi and Conda package managers. It operates using the FSLeyes interface, is written in python, is open source, and is available under the BSD 3‐clause license. FSLeyes is available under the Apache License, version 2.0. ⁷

This work enables NIfTI‐MRS formatted data to be displayed alongside arbitrary MRI and other modality imaging data formatted as NIfTI. It also enables the visualization of multidimensional NIfTI‐MRS data. Figure 5 shows two examples of NIfTI‐MRS data displayed in FSLeyes using the plugin.

FIGURE 5.

(A) MRSI data displayed in FSLeyes using the NIfTI‐MRS plugin. In addition to the NIfTI‐MRS data, results from spectral fitting (also stored in NIfTI format) are displayed overlaid on the spectrum, to the left a metabolite map of total choline is displayed overlaid on a T₁w structural image. The spectrum display automatically displays voxel‐wise spectrum and fits as the cursor is moved over the orthographic display. (B) Partially preprocessed single voxel data displayed in FSLeyes alongside corresponding structural data. Beneath the main spectral view panel, an additional panel “NIfTI‐MRS” (bottom‐right) displays a summary of the MRS specific header information contained in the file, and a slider UI element to allow the user to view each spectrum stored in the higher (5th–7th) dimensions. Here the tenth (of 64) temporal averages stored in dimension 5 is displayed

4. DISCUSSION

In this work, we have proposed NIfTI‐MRS as a new standard data storage format for MRS and MRSI. The standard was initially developed and agreed by a group of MRS physicists and researchers with experience in MRS analysis software use and development. Following a draft specification, feedback was sought from MRS software developers, experts in the field, and the wider technical MRS community. The standard and associated files are maintained online at Ref.19.

NIfTI‐MRS can provide a simplified analysis pathway and a path for interoperability of analysis programs, and greatly simplifies display and co‐interpretation of MRS data alongside other modalities. In addition, the standard fulfills several other desirable objectives:

• A standard data storage format is a prerequisite for incorporating MRS data into standardized data structuring schemes, such as in the Brain Imaging Data Structure (BIDS). ²⁵

• Similarly, a standard format allows for extensive and easy data archiving and sharing in open science databases, such as OpenNEURO ²⁶ , ²⁷ or MRS‐specific databases. ²⁸ One study ²⁹ has already utilized NIfTI‐MRS for the purpose of releasing study data on XNAT central (https://central.xnat.org/data/projects/PN21). And another has recently submitted data formatted as NIfTI‐MRS to the National Institute of Mental Health Data Archive (National Institutes of Health, Rockville, MD). ³⁰

• Standard header definitions and processing provenance make it easier for users to comply with minimum reporting standards consensus statements, ³¹ and to reproduce and recreate data analysis workflows simply by extracting the provenance information from a NIfTI‐MRS file users received

The developers of NIfTI‐MRS have sought to make the standard as accessible as possible. Spec2nii implements a mature open‐source program suitable for both one‐off and batch conversion tasks. NIfTI I/O libraries are available in all common programming languages, and minimal examples of readers have been provided. Support for NIfTI‐MRS is already available in five analysis packages (with further packages implementing the standard currently). This represents a critical mass of actively developed processing tools.

To date, spec2nii handles 14 different formats; however, complete coverage of sequences across such a diverse range of formats cannot be guaranteed. Currently, data must be in a spatially reconstructed format before conversion. Development of spec2nii has relied on a community‐led model, with users contributing examples, test data, and code contributions to the developers.

In this work, FSLeyes has been extended with a plugin to create an NIfTI‐MRS compatible data viewer. The authors consider this just an example of the existing tools present in the MR imaging community that can be easily leveraged for MRS and MRSI by using NIfTI‐MRS. NIfTI‐MRS mitigates the difficulty of aligning and registering MRSI data with MRI (and other modality) data, easing the simultaneous use of imaging and spectroscopic data to further methodological and analysis techniques in both fields.

The NIfTI‐MRS standard is versioned, enabling backward‐compatible future extension of the standard. The authors propose that the International Society for Magnetic Resonance in Medicine MRS Study Group Committee for Code and Data Sharing (www.mrshub.org/), established in 2020 as a permanent standing committee with rotating members, helps maintain oversight of the standard and any future development alongside the original authors.

Establishing a standardized data format for MRS is a requirement for MRS to be used for large scale cross‐center, or population, studies. The NIfTI format provided this for neuroimaging studies such as the Human Connectome Project. ³² Furthermore, the uptake of the NIfTI‐MRS standard shows the possibility of establishing an ecosystem of open‐source analysis toolboxes similar to that which has benefitted functional neuroimaging (e.g., AFNI, FSL, SPM). ³³ , ³⁴ , ³⁵ Nonetheless, this work does not tackle other key aspects such as communication of MRS fitting results.

5. CONCLUSION

NIfTI‐MRS has been designed to both promote the use of MRS in biomedical research and ease the technical development of MRS analysis in the wider field of biomedical imaging. The standard and associated tools are developed in an open‐research context. Further use and development of NIfTI‐MRS and associated tools are dependent on the expertise and contributions of the community, including MR hardware vendors. To date, the community has enthusiastically done so, enabling the rapid development of the standard and its inclusion in multiple software tools.

Funding Information

Support provided by funding from the Wellcome Trust and the Royal Society, grant 102584/Z/13/Z (William T. Clarke.); the National Institutes of Health (NIH), grants K99/R00 AG062230, S10 OD021648, P41 EB031771, P41 EB015909, R01 EB016089, R01 EB023963, and R01 EB028259 (Georg Oeltzschner); and funding from the European Union's Horizon 2020 research and innovation program under the Marie Sklodowska‐Curie grant agreement no. 813120 (Amir M. Shamaei.). The Wellcome Centre for Integrative Neuroimaging is supported by core funding from the Wellcome Trust, grant 203139/Z/16/Z.

Clarke WT, Bell TK, Emir UE, et al. NIfTI‐MRS: A standard data format for magnetic resonance spectroscopy. Magn Reson Med. 2022;88:2358‐2370. doi: 10.1002/mrm.29418

DATA AVAILABILITY STATEMENT

All source code and data examples can be found in the related GitHub repository, https://github.com/wtclarke/mrs_nifti_standard, release version 0.6.0 at time of publication.