Open chrboku opened 3 years ago
This will unfortunately happen for m/z with a lot of background noise. the noise estimation in xcms
uses the signal from ~ the same m/z not part of the peak. noise estimation works obviously better if the baseline noise is close to 0. In your case you have a huge background noise in the left part - xcms
finds that this signal is higher than the "background noise" further right and hence defines peaks there. what might help is some sort of background noise estimation and substraction to bring the noise down to ~ 0 - but that is unfortunately not possible in xcms
.
Okay. Thank you for your swift answer
Hello
I have run into the issue, that XCMS detects peaks where (at least to my understanding) there should not be any. An example is provided here![2021-04-29 09_13_02-Window - Copy](https://user-images.githubusercontent.com/18591761/116514858-e0e71480-a8cb-11eb-8e49-741a3de44f85.png)
While the three peaks on the right side of the EICs are okay, the large number of no-chromatograpic peaks detected as such is strange. I have been playing around with different parameters, especially increasing the snr-threshold, but that did not solve the issue as these peaks on the left have a huge snr value [1]
My code for producing this example is
The samples were recorded with an Orbitrap Exactive instrument in centroid data mode.
My question/issue: Is this expected? Why does XCMS calculate so high snr-values for these "peaks"
Thank you
[1]