Numerical Compression Schemes for Proteomics Mass Spectrometry Data

Abstract

The open XML format mzML, used for representation of MS data, is pivotal for the development of platform-independent MS analysis software. Although conversion from vendor formats to mzML must take place on a platform on which the vendor libraries are available (i.e. Windows), once mzML files have been generated, they can be used on any platform. However, the mzML format has turned out to be less efficient than vendor formats. In many cases, the naïve mzML representation is fourfold or even up to 18-fold larger compared with the original vendor file. In disk I/O limited setups, a larger data file also leads to longer processing times, which is a problem given the data production rates of modern mass spectrometers. In an attempt to reduce this problem, we here present a family of numerical compression algorithms called MS-Numpress, intended for efficient compression of MS data. To facilitate ease of adoption, the algorithms target the binary data in the mzML standard, and support in main proteomics tools is already available. Using a test set of 10 representative MS data files we demonstrate typical file size decreases of 90% when combined with traditional compression, as well as read time decreases of up to 50%. It is envisaged that these

BatMass: a Java Software Platform for LC–MS Data Visualization in Proteomics and Metabolomics

“…A custom data access library was developed for BatMass to fulfill the speed requirements (parsing speed is comparable to the C++ implementation from OpenMS) and to automate memory management. It provides a rich API for accessing scan meta-data and spectra, including support for MS-Numpress compression 23 in mzML files. As the API is separated from the implementation, it is possible to add support for other file formats as well.…”

The arc of Mass Spectrometry Exchange Formats is long, but it bends toward HDF5

“…In order to maintain the positive gains of the adopted format (in the form of desirable features such as universality and human readability), the developers of mzML compliant tools have had to engineer increasingly complex adjunct software in order to keep the resulting systems performant. Examples of this include the storage of image data in adjunct files external to the main mzML file in imzML (Römpp et al, ), the generation of external binary files (“.cachedMzML” files) by OpenMS to support efficient access to SWATH data stored in mzML (Röst et al, ), and the incorporation of the MS‐Numpress (Teleman et al, ) compression schemes into ProteoWizard (Chambers et al, ) to mitigate the up to 18‐fold inflation in mzML file size as compared to the original vendor format (Teleman et al, ). These software engineering fixes are all symptomatic of the technical drift arising from the choice of a text‐based format for the storage of increasingly large volumes of mass spectrometry data.…”

Compression strategies for the chemometric analysis of mass spectrometry imaging data

“…There are several examples of applications in which chemometric tools are used to discriminate between samples and to identify potential biomarkers in biomedical, environmental, or food fields. However, there are extreme cases in which the dimensionality of the data generated makes the direct application of these methods impractical owing to the high computational requirements . An example of this limitation lies in the metabolomic analysis of data obtained by chromatographic techniques coupled with a high‐resolution mass spectrometric detector.…”

“…However, there are extreme cases in which the dimensionality of the data generated makes the direct application of these methods impractical owing to the high computational requirements. 9 An example of this limitation lies in the metabolomic analysis of data obtained by chromatographic techniques coupled with a high-resolution mass spectrometric detector. In this case, each sample generates a data matrix in which each retention time (each row) contains a complete mass spectrum formed by several thousands of m/z values (columns).…”