-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a function that calculates peak quality metrics for detected peaks #705
Comments
I don't have strong opinions on it, honestly! I agree that |
Agree - and I like your suggested name - maybe slightly reformulated into |
I like it! Sounds good to me. |
Alignment with the mzQC folks might be nice. https://github.com/HUPO-PSI/mzQC |
that's obviously the better approach - maybe have a generic |
A generic function that returns the metric of choice would be great. I currently have William's function snippet (data is an
|
To avoid adding too many functions (also thinking of the future) maybe good to add a
similar to all other |
Hi @jorainer if I understand correctly what you want to do then there are several metrics defined by the PSI working groups. Have a look |
Had a look through the obo. The only actual quality metric of an EIC (or XIC as they are called in the obo) is the FWHM (full width at half maximum, MS:1000086). The obo related obo terms are MS:4000017 (chromatogram metric) or more specific MS:4000018 (XIC quality metric). |
Yeah, we struggled to find a lot of standardized "peak quality" definitions in the literature when working on the original project as well. The Kantz 2019 paper uses six quality metrics and a bunch of combinations of them (peak duration, height, area, FWHM, tailing factor, and asymmetry factor). Your 2022 CPC paper @jorainer has some of these implemented already (looks like everything except asymmetry factor, though the noise estimation is likely different). We used the outputs from XCMS (mz, rt, peakwidth, area, sn, f, scale, lmin) but didn't test on the additional metrics of verboseColumns. I do think it's worth calculating an m/z deviation (and maybe an m/z deviation from mean m/z ~ intensity) metric even though that didn't show up especially strongly in my dataset, and I also think that a metric for the "number of missing scans" would be really nice to have, though again my custom implementation wasn't especially powerful in my dataset. |
Recently (PR #685), new quality score metrics can be calculated during centWave peak detection. Would be good to have also a function that allows calculation of these scores on already detected chrom peaks (i.e. after peak detection) or also directly on EICs.
While straight forward to implement, naming is again an issue. @wkumler do you have a suggestion/appropriate name for your new peak quality metrics we could use? Using
chromPeaksQuality
as function name might be a little too generic maybe.The text was updated successfully, but these errors were encountered: