request: write centroids to mzML

[LeonSaal]

Hi Daniel,

maybe you asked yourself, why I want to use already centroided data in the first place when I have profile data available:
My plan is to integrate the results from qAlgorithms into another workflow, that uses centroided mzML-data.
For that matter I would like it, if they both worked with the same input data.

So it would be great, if the centroids could be exported as mzML as an intermediary results from the qAlgorithms-workflow.

Kind regards,

Leon

[dahoehn]

Hello Leon,
while i see why you would do that, i don't think it will work as well as relying on the generated feature list. The main reason is that we produce everything which is statistically significant, leading to a high amount of centroids overall. In fact, most of these are false positives, even if they have a very good DQSC.
To illustrate this problem, try your analysis workflow using this dataset: https://zenodo.org/records/14194451
It contains no real (i.e. relating to a chemical compound) signals whatsoever, but a lot of centroids are identified regardless. When using a different centroiding approach, at least some will likely be knocked out by an intensity filter of sorts. The main point of producing this many centroids is to not produce false negatives before the binning step, during which even very small mass differences can prevent grouping. You could consider using only the binned centroids produced with the -pb option for your comparison.

To answer your question, i do not plan on implementing a mzML export both for the described reasons and because the main point of qAlgorithms - the quality scores - would (probably) not be considered by other algorithms. The "roadmap" is focused on expanding the scope of qAlgorithms to componentisation and eventually trend analysis for now.

Greetings,
Daniel

[LeonSaal]

Hello Daniel,

thanks for the detailed reply.
However my plan is not to only use the centroids, but to import the qPeaks-features into the other workflow. The point of the other workflow at least for now is to perform further processing steps i.e. grouping, componentization, annotation and so on. This is also related to #7.

Kind regards,

Leon

[dahoehn]

Hello Leon,
we are currently working on componentisation, so feel free to use this issue for your requests and needs in this regard.

While i might implement feature-export as mzML going forward, i do not think XML type organisation is the correct way to handle feature lists. For the moment, we will stick with human-readable csv, mostly since that is the standard for feature list communication i see used most often. What i believe to be the best solution in this regard is a new file format which encompasses information regarding experimental setup, hashes of replicates and complete processing information in addition to the MSn spectra.
Due to time constraints, we will only put work into maintaining export functions once our output is static - this includes developing new ones.

Greetings,
Daniel

[LeonSaal]

Hello Daniel,

there has been a misunderstanding.
This is what I'd like to achieve:

But I understand, that you have time constraints and other priorities.

Kind regards,

Leon