You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
we should test the reading and peak picking functions some time in the future how well it handles peculiarities in IMS data.
An addendum to the mzML spec says:
There was some concern that in the original mzML 1.1 format there should never be two
identical m/z values in an “m/z array”. But this was not explicitly stipulated in the mzML 1.1
specification, and with the addition of ion mobility arrays, repetition in the “m/z array” will be
common (having differing ion mobility array values). This means that all mzML parsers SHOULD
be checked/updated to handle mzML data with non-increasing (identical or decreasing) m/z values
in the "m/z array". All parsers SHOULD also be updated to warn or halt gracefully if they are not prepared
to handle the kinds of data described herein.
This has time until a suitable collection of example mzMLs are available,
but I wanted to note this somewhere for reference.
Yours, Steffen
The text was updated successfully, but these errors were encountered:
Good point. In some functions in Spectra (and for some backends) we check if or ensure that m/z values are ordered. AFAIK all our functionality should be safe even if m/z values are not ordered. The only functions where it is critical are the m/z comparison, grouping and binning functions in MsCoreUtils. But these by default check for ordered m/z values.
xcms uses now also Spectra et al - so it should suffice if we fix it there.
Hi,
we should test the reading and peak picking functions some time in the future how well it handles peculiarities in IMS data.
An addendum to the mzML spec says:
This has time until a suitable collection of example mzMLs are available,
but I wanted to note this somewhere for reference.
Yours, Steffen
The text was updated successfully, but these errors were encountered: