Maybe you can describe what you are trying to do in some more detail.
obiwarp can only be applied to pairs of samples, retcor.obiwarp calculates retention time correction as a center-star alignment, based on the samples in the xcmsSet. It creates the corrected retention time vectors (xcmsSet@rt$corrected) and eventually updates the the retention times in the @peaks table.
Using the grouping information (indices) from the group'ed xcmsSet, you can simply pull out all the values you need from the full peak matrix and calculate the S/N statistics for each feature as needed.
Looks like R 3.0 does not support the packages that were build using R versions < 3.0. I'll update the binary package (.zip) soon, in the meantime you could try installing it using the source package (.tar.gz).
The solution for this problem is described here. You have to use the "sortByScanTime" filter to make sure the scans are in the right order in the mzXML file.
Since the msconvertGUI does not seem to support the "sortByScanTime" filter at the moment you have to do the conversion on the command line, using something like
If you really want to apply obiwarp without doing feature detection first, you could implement a simple "dummy" feature detection method, that does nothing but returns an empty peak matrix. That way you could call xcmsSet(method="dummy",...) to create an xcmsSet that has all the meta-information and could be used to apply obiwarp. The xcmsSet will then contain the new retention time vectors (but no peaks).
R is crashing with a segfault when trying to run GTK. I guess I would try to completely remove GTK+ and RGtk and then reinstall, maybe even on on a new R installation. If that doesn't help you would need to contact the maintainer of the RGtk2 package.
We also have an alpha-release of the online version of metaXCMS available if you want to try it I can give you some details via PM.
I do not recommend downgrading metaXCMS to 0.1.19. You might get strange results unless you use it in combination with XCMS versions >= 1.35.7. The only difference between metaXCMS 01.1.19 and 0.1.20 is a hardwired group.nearest() function from an older version of XCMS, a version that was known to work well with metaXCMS.
It turned out that there was a serious bug in XCMS' group.nearest (in XCMS versions 1.33.4 - 1.35.6) which completely ignored the peaks from the first sample. This bug was fixed in XCMS 1.35.7.
Anyway, without the actual data I'm unable to reproduce this problem. I just tried using the combination of R 3.0.0 and metaXCMS 0.1.20 and the data from the Nature Protocol and everything works as expected.
Can you try again please? There was a problem with the java uploader in the recently released new version of XCMS Online which resulted in an MD5 error for some users. It should work now.
These peaks look weird. At this relatively high intensity they should have a better shape. Is this HILIC or RP data? What kind of mass spec is this? And what are your centWave parameters (ppm) ?
Only the core region of your features seem to be within within that 30 (?) ppm window, it looks pretty wild outside of that core region. You don't want these m/z values to be included into the m/z calculation, but for a smooth looking EIC you might want to open up the m/z window.
CAMERA uses getEIC for EIC extraction, so the results will depend on the profstep parameter of your xcmsSet.
A ROI can contain multiple features. centWave makes an effort to assign both retention time and m/z range precisely for each individual feature found within one ROI. The m/z center of a feature is calculated using the m/z values of the centroids within this range, so it is trying to get that m/z range as narrow as possible. It is possible that there is a problem with numeric precision when you try to extract the EICs using the exact boundary values. you might want to try adding a little bit of slack like +/- 0.0001. But please let me know if you should find an example where some centroids that you think belong to a feature are located outside the given m/z range (by the way, the equivalent to rawEIC is rawMZ for the m/z domain, e.g. mz <- rawMZ(object,mzrange=mzrange,scanrange=scrange) )
