Menu
▾
▴
Re: [Psidev-ms-dev] additional feature request: contiguous/noncontigous marker for m/z array data?
|
From: Joshua T. <jt...@sy...> - 2008-04-16 17:15:03
|
Hi Darren, You did understand what I meant. I've been working with the Agilent MassHunter-format machines which give huge non-thresholded profile arrays (at least currently), where I'd like to make note of data reduction that might be applied at conversion time-- and make it easier for the parsers to handle "choppy profile" data. However, if Thermo data already looks that way (I didn't realize), maybe it's not necessary. I incorrectly believed that "profile" implied "no gaps in m/z spacing". -Josh Darren Kessner wrote: > What is the use case for this? > > I think everyone has an intuitive understanding of "contiguous", but I > think it is a little more complicated to define properly. The > intuitive definition is "regularly spaced with no missing data points". > > When accessing profile data in RAW files from Thermo FT instruments, > the spectra are thresholded, and this gives rise to the islands that > Josh mentioned during the conference call. However, in FT data > without islands (e.g. if thresholding is disabled, or perhaps with > preprocessing to extract a single island or fill in missing data > points), the data points are still not regularly spaced in m/z. (The > data points are regularly spaced in frequency space, but the frequency- > >m/z calibration function is non-linear). Because the data points > are not regularly spaced, any processing must use some form of > interpolation, so I'm not sure how a "contiguous" flag will help. > > > Darren > > > > On Apr 16, 2008, at 6:48 AM, Eric Deutsch wrote: > >> From: Joshua Tasman >> >> Hi all, >> >> There are cases where the m/z array data is contiguous (standard >> profile >> mode) vs noncontiguous (centroided, or thresholded profile). Could >> we add >> an attribute to the binary array section (or above) describing >> this? Or is >> this best left to the parsers to automatically determine? >> >> One tricky case that might not be quickly/easily scanned for: >> imagine a mode >> that preserves profile data points around detected peaks; so the >> first large >> # of data points might appear to be the same m/z delta. Hence, a >> quick >> check by the parser might not get this correct. >> >> Thanks for considering, >> >> Josh >> >> >> >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save >> $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
