sneumann / xcms

This is the git repository matching the Bioconductor package xcms: LC/MS and GC/MS Data Analysis
Other
178 stars 81 forks source link

Peaks are detected in background #558

Open chrboku opened 3 years ago

chrboku commented 3 years ago

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

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

  library(xcms)     ## 3.12.0
  library(magrittr)

  polarity="positive"
  fls <- dir(paste0(rootPath, "/", polarity), full.names = TRUE, recursive=TRUE)
  fls = fls[1:3]

  data <- readMSData(fls, mode = "onDisk") 

  #data %>%
  #  filterMz(mz = c(371.1, 371.102)) %>%
  #  chromatogram(aggregationFun = "max") %>%
  #  plot() 

  #' Get the XIC for serine in all files
  srn_chr <- chromatogram(data, rt = c( 200, 2100),
                          mz = c(371.1, 371.102),
                          aggregationFun = "max")

  cwp <- CentWaveParam(peakwidth = c(12, 30), integrate = 1, verboseColumns = TRUE, fitgauss = TRUE)

  srn_chr <- findChromPeaks(srn_chr, param = cwp)

  plot(srn_chr)
  chromPeaks(srn_chr)

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]

            rt    rtmin    rtmax     into     intb      maxo     sn f scale scpos scmin scmax lmin lmax row column
 [1,]  215.435  205.823  226.233  7605119  7605097  404031.3 404030 2     5    13     8    18    5   22   1      1
 [2,]  235.850  227.453  246.641  6952960  6952940  402306.6 402306 2     7    30    23    37   23   39   1      1
 [3,]  290.953  261.008  292.169 11096202 11096169  433597.4 433596 4    13    76    63    89   44   70   1      1
 [4,]  327.999  310.078  341.136 10741753 10741721  441309.6 441309 5     7   107   100   114   63   89   1      1
 [5,]  369.827  360.255  379.391  6747520  6747499  423734.5 423733 7     5   142   137   147   68   84   1      1
 [6,]  390.147  379.391  400.905  7592197  7592175  407834.2 379267 7     5   159   154   164   84  102   1      1
jorainer commented 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.

chrboku commented 3 years ago

Okay. Thank you for your swift answer