mzML Profile and Centroid Spectra Carry Different Peak Information

Identify what the receiving pipeline needs

Begin at the component that receives the offered data. Does it require intensity samples around each peak, or a list containing one coordinate and intensity per peak? An mzML file can support either representation. HUPO-PSI's model objectives explicitly include profile and centroid data, so agreement on the extension leaves this choice open.

The PSI-MS vocabulary defines profile spectrum, MS:1000128, through intensity distributed across a peak's coordinate range. Centroid spectrum, MS:1000127, records each peak as one discrete coordinate with a corresponding intensity. For the m/z spectra discussed here, those coordinates express mass-to-charge ratio. A profile sample and a centroid peak therefore occupy different roles even when both appear as coordinate/intensity pairs.

This explanation uses the main mzML schema 1.1.1 and PSI-MS controlled vocabulary 4.2.6, dated October 14, 2026. The schema version and vocabulary version identify different resources. Neither version number selects the representation required by a particular model pipeline.

References: [PSI-R][PSI-CV][PSI-X][PSI-OV]

Count spectra, arrays and paired points separately

The CV names the m/z array, MS:1000514, and intensity array, MS:1000515. Read their values position by position: the first coordinate corresponds to the first intensity, and so on. Two arrays can describe many paired points; they do not mean two peaks.

Under main schema 1.1.1, spectrumList count counts spectra, binaryDataArrayList count counts arrays, and defaultArrayLength defines a spectrum's default array length. Its m/z and intensity arrays follow that length; arrayLength overrides are not for them. Six entries in each array therefore form six paired points, not twelve.

Representation determines how to interpret those points. Six profile points need not be six peaks. Two centroid points represent two peaks in the stipulated case below. These counts alone supply no file-size, bandwidth or memory estimate.

References: [PSI-CV][PSI-X]

MZ-REP6: P supplies six profile samples

Consider two fictional export offers, P and C. Each supplies one spectrum and exactly two default arrays, one for m/z and one for intensity. P is stipulated to be profile data; C is separately stipulated to be centroid data. No acquisition, conversion or model evaluation was performed. The example's intensity numbers carry no physical unit or calibration claim.

P declares profile spectrum MS:1000128 and defaultArrayLength 6. Its m/z array is [199.9, 200.0, 200.1, 299.9, 300.0, 300.1]. Its corresponding intensity array is [2, 10, 3, 1, 8, 2].

Pairing by position gives (199.9, 2), (200.0, 10), (200.1, 3), (299.9, 1), (300.0, 8) and (300.1, 2). The case stipulates two peak neighborhoods, with three supplied samples in each. Around 200.0, the sampled intensity rises from 2 to 10 and falls to 3. Around 300.0, it rises from 1 to 8 and falls to 2.

Those sampled rises and falls are information available to a consumer using local peak shape. P supplies six such coordinate/intensity pairs. It does not specify a continuous curve between them or provide samples throughout the gap between the two neighborhoods.

References: [PSI-CV][PSI-X]

C supplies two discrete peak pairs

C declares centroid spectrum MS:1000127 and defaultArrayLength 2. Its m/z array is [200.01, 300.02], and its corresponding intensity array is [14, 11]. Its two pairs are therefore (200.01, 14) and (300.02, 11).

These are separately stipulated values. The intensities 14 and 11 are not calculated from P: they are not supplied as sums, peak areas or maxima. No centroiding algorithm, conversion relationship or equivalence between the two offers is given. In particular, the second value's numerical coincidence with 1 + 8 + 2 = 11 establishes no processing rule.

C identifies two discrete peak coordinates and intensities. Those pairs alone do not specify P's six sample coordinates or their six intensities. C contains no value stating that the intensity at 199.9 was 2, for example. Adding points around 200.01 would require additional information or an assumed construction; it would not demonstrate recovery of the supplied profile samples.

Both offers still contain one spectrum and two arrays. Their common container counts conceal the difference between six profile samples and two centroid peaks. The missing information for a profile-sensitive request is the local distribution of supplied samples, not an additional spectrum.

References: [PSI-CV][PSI-X]

Apply each offer to the stated input requirement

First stipulate that the receiving component requires the local samples in MZ-REP6's two peak neighborhoods. P supplies those six pairs and lets the component distinguish the sampled rise and fall on either side of each central coordinate. C alone leaves that request unanswered: a single intensity at 200.01 does not supply the three requested profile samples around 200.0.

Now stipulate a different consumer that requires one centroid coordinate/intensity pair per peak, with an accepted definition of the intensities. C supplies that structural form. P's six profile points cannot simply be relabeled as six centroid peaks. If the proposed delivery includes a transformation, its provider must identify the actual resulting representation and the intensity meaning accepted by this consumer.

The requirement changes which offer addresses the input question. Neither the larger point count nor the profile label establishes a universally preferable input. A peak-list consumer can use the distinctions supplied by centroid data, while a profile-sensitive consumer needs the distributed samples relevant to its task.

This comparison establishes a representation difference, not a model-quality ranking. A complete offer must connect the delivered values to the actual consumer's requirements; a promise that both files are mzML-compatible does not make that connection.

References: [PSI-R][PSI-CV]

Keep the processing history attached to the export

HUPO-PSI defines peak picking, MS:1000035, as processing that converts profile data to centroided data. The general term supplies no universal numerical rule for producing the coordinates or intensities. The mzML model objectives also identify centroiding as data reduction that can occur when producing peak lists.

The spectrum-list defaultDataProcessingRef and optional spectrum dataProcessingRef identify declared processing. Each processingMethod has an order and softwareRef; the referenced software entry includes its version. These relationships help identify which declared processing and software apply to an offered spectrum.

For a real offer, have the producer explain the applicable references and any processing between the export and the receiving component. A source export can contain profile data while a later supplied input contains centroid peaks. Evidence about the source stage alone would not describe that later input.

Processing metadata provides provenance to assess alongside the actual delivered values. A reference or representation label does not independently demonstrate that the described processing occurred, that the data agree with it or that acquisition was correct.

References: [PSI-CV][PSI-R][PSI-X]

Ask for an explanation tied to the delivered input

A useful supplier response names the offered export and spectrum subset, then explains what reaches the identified receiving component. For a profile request, it should account for the retained coordinate/intensity samples and their correspondence. For a centroid request, it should account for the supplied peak pairs and the meaning of their intensities. In either case, retain the actual coordinate and intensity units and the applicable producer and processing information.

In MZ-REP6, a response saying one spectrum with two arrays describes both P and C and cannot settle the choice. A response identifying P's six profile pairs addresses the stipulated local-sample request. A response identifying C's two centroid pairs addresses the stipulated peak-list form, with intensity interpretation still governed by that consumer's requirement.

Resolve the deliverable at that boundary before comparing claims about downstream suitability. The related FASTQ and packed NetCDF articles address other input-meaning questions: quality-character interpretation and missing-value handling. Their checks complement this one, but cannot substitute for identifying the spectrum representation.

Scope a separate equipment installation need

If the wider project also needs customer-selected compute, storage or network equipment physically installed, Leviathan's Rack-and-Stack & Colocation Installation service provides a route to discuss agreed mounting, IT cabling, labels and physical installation records.

Use the related service and project inquiry with a nonconfidential equipment list, rack layout, connection requirements, site authorization and desired work window to discuss scope and availability. That inquiry concerns the physical installation. Mass-spectrometry data preparation, centroiding, bioinformatics and AI software remain with the appointed specialist providers.

References: [L1]