Found in a cross-vendor parity audit of the OpenMassSpec stack.
Calibration::scan_to_inv_mobility converts raw mobility scan numbers to 1/K0 (both per-spectrum-mean and, since #8/PR#12, per-peak via inv_mobility_per_peak), but there's no further conversion to collision cross section (CCS) anywhere in the crate - confirmed zero hits for "ccs"/"CCS"/"cross section" in crates/opentimstdf/src/.
1/K0 is instrument- and condition-dependent in a way CCS (via the Mason-Schamp equation) isn't, so this is the difference between "has ion mobility data" and "ion mobility data usable for cross-instrument/spectral-library comparison" - the primary reason people reach for timsTOF 4D-proteomics data in the first place. Bruker's own tooling (and most open reimplementations, e.g. alphatims) compute CCS from 1/K0 plus charge state and a couple of physical constants (reduced mass, buffer gas), so this should be a more tractable closed-form conversion than OpenWRaw's TWIMS equivalent (see Sigilweaver/OpenWRaw#10, filed alongside this one - CCS is unimplemented for both IMS-capable vendors in the stack).
Proposed scope: add a Calibration method (or free function) computing CCS from 1/K0 + charge + temperature/gas constants, and expose it alongside the existing inv_mobility/inv_mobility_per_peak fields - either as new SpectrumRecord fields (needs an OpenMassSpecCore schema change, since CCS has no home there currently either) or as a reader-level convenience that mzML export doesn't carry, TBD by whoever scopes it.
Found in a cross-vendor parity audit of the OpenMassSpec stack.
Calibration::scan_to_inv_mobilityconverts raw mobility scan numbers to 1/K0 (both per-spectrum-mean and, since #8/PR#12, per-peak viainv_mobility_per_peak), but there's no further conversion to collision cross section (CCS) anywhere in the crate - confirmed zero hits for "ccs"/"CCS"/"cross section" incrates/opentimstdf/src/.1/K0 is instrument- and condition-dependent in a way CCS (via the Mason-Schamp equation) isn't, so this is the difference between "has ion mobility data" and "ion mobility data usable for cross-instrument/spectral-library comparison" - the primary reason people reach for timsTOF 4D-proteomics data in the first place. Bruker's own tooling (and most open reimplementations, e.g. alphatims) compute CCS from 1/K0 plus charge state and a couple of physical constants (reduced mass, buffer gas), so this should be a more tractable closed-form conversion than OpenWRaw's TWIMS equivalent (see Sigilweaver/OpenWRaw#10, filed alongside this one - CCS is unimplemented for both IMS-capable vendors in the stack).
Proposed scope: add a
Calibrationmethod (or free function) computing CCS from 1/K0 + charge + temperature/gas constants, and expose it alongside the existinginv_mobility/inv_mobility_per_peakfields - either as newSpectrumRecordfields (needs an OpenMassSpecCore schema change, since CCS has no home there currently either) or as a reader-level convenience that mzML export doesn't carry, TBD by whoever scopes it.