From: Christopher M. <Mas...@ma...> - 2008-02-21 19:13:20
|
Darren- I missed the phone call but I'm curious about your use of mzML with Fourier instruments / transients. What instrument were you contemplating using this with? With what kind of transient sizes? On an Orbitrap or LTQ-FT with 1-2 Mword transients, aren't we talking around 2-4 mbytes per transient even before base64 encoding? In my experience, the don't compress very well either. This is the use case I've always worried about with any xml data format. Thanks, -c |
From: Christopher M. <cm...@cm...> - 2008-02-21 19:12:38
|
Darren- I missed the phone call but I'm curious about your use of mzML with Fourier instruments / transients. What instrument were you contemplating using this with? With what kind of transient sizes? On an Orbitrap or LTQ-FT with 1-2 Mword transients, aren't we talking around 2-4 mbytes per transient even before base64 encoding? In my experience, the don't compress very well either. This is the use case I've always worried about with any xml data format. Thanks, -c |
From: Matthew C. <mat...@va...> - 2008-02-21 19:18:19
|
It might not respond well to zlib compression, but wouldn't this kind of data be well-suited to any other kind of compression designed to capitalize on the relatively small differences between sequential elements? The mzXML ruler style compression, perhaps? -Matt Christopher Mason wrote: > Darren- > > I missed the phone call but I'm curious about your use of mzML with > Fourier instruments / transients. > > What instrument were you contemplating using this with? With what kind > of transient sizes? On an Orbitrap or LTQ-FT with 1-2 Mword transients, > aren't we talking around 2-4 mbytes per transient even before base64 > encoding? In my experience, the don't compress very well either. > > This is the use case I've always worried about with any xml data format. > > Thanks, > > -c > > |
From: Kessner, D. E. <Dar...@cs...> - 2008-02-21 19:27:12
|
I haven't played around with compressing transient data, but I would guess that Matt's hunch is right that there is some compression strategy that would work, at least enough to offset the Base64 bloat. The hope (possibly naive) is that instrument vendors like Thermo would be willing to write out the transient data directly into mzML, so that we don't have thousands of these transient data files sitting around. But Christopher has a good point that a 10GB mzML file may be too unwieldy to deal with. Darren -----Original Message----- From: psi...@li... [mailto:psi...@li...] On Behalf Of Matthew Chambers Sent: Thursday, February 21, 2008 11:18 AM To: Mass spectrometry standard development Subject: Re: [Psidev-ms-dev] Transient data. It might not respond well to zlib compression, but wouldn't this kind of data be well-suited to any other kind of compression designed to capitalize on the relatively small differences between sequential elements? The mzXML ruler style compression, perhaps? -Matt Christopher Mason wrote: > Darren- > > I missed the phone call but I'm curious about your use of mzML with > Fourier instruments / transients. > > What instrument were you contemplating using this with? With what kind > of transient sizes? On an Orbitrap or LTQ-FT with 1-2 Mword transients, > aren't we talking around 2-4 mbytes per transient even before base64 > encoding? In my experience, the don't compress very well either. > > This is the use case I've always worried about with any xml data format. > > Thanks, > > -c > > ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Psidev-ms-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED. If you have received this message in error, please notify us immediately by calling (310) 423-6428 and destroy the related message. Thank You for your cooperation. |