Navigating the MS imaging software landscape means choosing between tools that answer genuinely different questions — not competing versions of the same thing. Knowing what each is actually built for, and understanding the open format that lets data move between them, prevents the most common and most painful mistake in this area: discovering a format lock-in only after a study is finished.
Key Takeaways
|
The MSI Software Landscape
As set out in Analyzing Mass Spectrometry Imaging Data: Processing, Statistics, and Multimodal Integration, the software choice splits along two axes: open versus commercial, and purpose-built for imaging versus adapted from general mass spectrometry. This article works through what specific tools on each side of that split are actually built to do, since the practical differences matter more than the category labels.
The three names that recur most often in this field occupy genuinely different roles rather than competing directly. One is a commercial platform tightly integrated with instrument acquisition. One is an open-source statistical analysis package. One is a community annotation service rather than a general-purpose analysis tool at all. Treating them as interchangeable options in a feature comparison misses the point; the useful question is which stage of the workflow each one serves.
Working in analytical science?
Register for a FREE Separation Science account to subscribe to the Separation Science Newsletter.
Vendor Tools: SCiLS Lab
SCiLS Lab is a commercial software platform developed for visualizing, processing, and statistically analysing MS imaging data, tightly integrated with instrument acquisition workflows from its manufacturer. Its role in a typical pipeline is usually the first point of contact with the data: initial visualization, region-of-interest selection, and standard statistical comparisons, run in an environment already connected to how the data was acquired.
That integration is the genuine advantage of a vendor-supplied platform generally, not specific to any one product: less friction moving from acquisition to first look, and support from the instrument manufacturer when something in that pipeline breaks. The trade-off is equally general. A platform built around one manufacturer’s acquisition workflow is not designed with data portability as the first priority, which is precisely why an open interchange format matters, covered in the next section.
Open-Source Tools: Cardinal and METASPACE
These occupy two different functions entirely, and conflating them is a common error. Cardinal is a statistical analysis package: an R implementation built specifically for MSI experiments, offering spatially aware segmentation, classification with cross-validated error estimation, and a processing pipeline that handles preprocessing through to formal statistics. Its role is analytical depth, particularly for a reader who wants to apply or extend a specific statistical method rather than use a predefined menu of options.
METASPACE is not a general analysis tool at all. It is a community annotation service specifically for assigning metabolite and lipid identities to imaging data at a controlled false discovery rate, covered in full in Metabolite Annotation and Databases for MS Imaging. A workflow does not choose between Cardinal and METASPACE as alternatives; a workflow typically uses Cardinal, or an equivalent, for processing and statistics, and METASPACE, or an equivalent, for the separate and later question of what the resulting features actually are.
Both are free and open, which carries a real advantage beyond cost: the methodology is published and inspectable, which matters when a reviewer or collaborator asks exactly how a segmentation or an annotation confidence score was calculated. A commercial platform\u2019s internal algorithm may be documented only at the level a user manual provides.
What Is imzML, and Why Does It Matter?
imzML is the open data format that makes it possible to move an MSI dataset between the tools discussed above without converting or recreating it at each step — and the mechanism behind that is worth understanding rather than treating as a black box.
Two Files, Linked by a Single Identifier The format was developed specifically to allow flexible and efficient exchange of MS imaging data between different instruments and analysis software. It splits the data into two separate files. Experimental metadata, instrumental parameters, sample details, and imaging-specific information such as pixel position, are stored in an XML file built on the HUPO-PSI mzML standard, whose original controlled vocabulary was extended specifically to describe imaging parameters. The mass spectral data itself is stored separately in a binary file for efficient storage. The two files are connected by offset values and unambiguously linked by a universally unique identifier. That split is the practical reason imzML works at scale: the metadata file can be read, indexed, and queried quickly without touching the much larger binary spectral file, so software can browse or search a dataset\u2019s structure before committing to loading gigabytes of spectra. Any software supporting the format can open a dataset acquired on any instrument that exports it, which is what breaks the dependency on a single vendor\u2019s tool. |
The practical benefit runs in two directions. A researcher is no longer limited to proprietary software and can choose the processing tool best suited to a specific question, which is precisely the point made in the software landscape section above. And measurements from different instruments can be compared within a single software application using identical processing settings, which matters for any study combining data from more than one acquisition system.
Is imzML a Finished Solution?
No, and knowing that shapes a sensible long-term data management decision rather than treating the format as permanently settled. Modern instrumentation, including higher resolution, faster acquisition, and ion mobility, has increased data volume and complexity considerably since imzML was introduced, and the format is showing strain under that growth.
Recent format development work states the position directly: current open formats including mzML and imzML struggle to keep pace with modern MS workflows due to large file sizes, slow data access, and limited metadata support, while vendor-specific formats offer faster access but lack interoperability and long-term archival guarantees. A next-generation community format, combining efficient binary storage with richer human- and machine-readable metadata, is in early development specifically to close that gap for high-throughput, multidimensional MS workflows including imaging and ion mobility.
The practical implication for a working laboratory is not to wait for a successor before adopting an open format now. imzML remains the current, widely supported standard and using it is unambiguously better than relying on a single vendor’s proprietary format. The implication is narrower: treat format choice as a decision to revisit rather than a permanent commitment, and keep an eye on interchange standards the way you would keep an eye on instrument software updates.
Building a Processing Workflow
A realistic pipeline frequently spans more than one piece of software, and imzML compatibility is what makes that combination practical rather than painful. Four principles help.
- Export to an open format as early as possible. Converting to imzML immediately after acquisition, rather than working in a vendor format until a specific need forces conversion, keeps every later option open.
- Match the tool to the task, not the task to the tool. Initial visualization and instrument-side quality checks suit a vendor platform’s integration; a specific statistical method suits an open package built for it; identity assignment is a separate annotation step entirely.
- Keep processing parameters with the data. Because a workflow may pass through more than one tool, recording which preprocessing and normalization settings were applied at each stage matters more here than in a single-tool pipeline, and is easy to lose track of across a handoff.
- Confirm format support before committing to a new tool. A tool that reads but does not fully write imzML, or that requires a lossy conversion, can quietly narrow your options later. Check both directions, not just import.
Machine learning approaches, which increasingly sit alongside or inside this pipeline for segmentation and feature extraction, are covered in Machine Learning for Mass Spectrometry Imaging Data. For the statistical and multimodal integration questions this processing feeds into, see Analyzing Mass Spectrometry Imaging Data: Processing, Statistics, and Multimodal Integration, and for where data analysis sits within the wider spatial landscape, Spatial Analysis in Analytical Science: Mass Spectrometry Imaging and Spatial Omics.
This article was produced under Separation Science's AI Editorial Guidelines.
