Yes, different tools can differ in how sensitive they are to certain types of bias. Ideally, you don't have any systematic bias in the entrapment but that is really hard to accomplish. That is why we usually cross check several different strategies for entrapment.

you get raw quantities only up till Precursor level (EG in the report). Running MaxLFQ twice on two different input quantities usually does not make sense. You would need to disable normalization and export the PG level quantities again after that.

The absolute scale of reported abundances is more or less arbitrary. For DIA data, what is typically reported is area below the XIC peak. Deal with that, the question becomes whether you integrate over seconds ore minutes. Makes an absolute difference of 60x but the choice is arbitrary.

Yes, that was one of the use cases we had in mind with this

For the name "Kuiper" I wanted to continue the space-theme we have going in Spectronaut. Kuiper was good fit for the name as like the Immuno-Class 1 search space, the Kuiper belt consists of millions of small objects.

And I would like to see how Fragpipe 22 does on an unspecific open search of a cell lysate (7 to 52 peptide length) in comparison to Kuiper.

The focus for Kuiper was on tackling unspecific searches. The open-search aspect was an unplanned side effect of how the unspecific engine was designed and fell into place almost by itself.

That is incorrect. Kuiper at its core is an open search engine. We simply chose to only report those matches we can afterwards resolve against existing modifications rather then reporting a list delta masses. Calling it "not truly open" is a technicality at this point.

Regarding the pre-print question, no we have kept it a tight secret till ASMS. We do have a it planned though to writing a paper about it.

And I can't wait to hear your feedback 😁

No, not at all. Obviously for runtime it pays off to have a fast CPU but in terms of memory, Kuiper is incredibly light weight.

One important part I forgot to mention, but Kuiper is completely data driven (purely an algorithmic solution) that is not dependent on any pre-trained HLA predictors. You don't need any prior knowledge of your samples to do a library-free, directDIA search using SN20 and Kuiper.

Working on Kuiper was a lot of fun. From the first prototype developed roughly a year ago, to the first integrated version in October to countless improvements and optimizations all the way to what was released now in Spectronaut 20. Looking forward to all of your feedback.

Oli

But one of the coolest things about Kuiper, I already teased in an earlier post. Kuiper is so powerful, that you can do an unspecific open modification search on a full 7-52 length cell-lysate search space with only a minor increase in search time compared to a closed search.

We obviously spent a lot of time making sure that the results you get are trustworthy. Not only from a statistical point of view but also using biological result validation. e.g.: we could show that the overlapping peptides between individual patients correspond to their shared HLA allele.

The runtime improvements are what is most impressive in my eyes. We can now do unspecific class-1 and class-2 in ~10 minutes per DIA raw file (library free, directDIA including all steps). That marks a 78% and 86% reduction in search time compared to SN19.

Our focus was primarily on immunopeptidomics (class 1 and 2) which is where you will see the biggest total gains in terms of IDs (+75% on average for class-1 and +18% for class-2).

Kuiper is a novel search-engine unlike anything you have seen before. It uses a new approach for MS2 indexing that is incredibly light-weight (full unspecific MS2 index of a 7-52 peptide length search space only occupies about 5GB in memory). Together with Pulsar, it can process DIA as well as DDA.

Most search-engines today start their development focus on the tryptic search case and are then expanded to other use-cases. We thought "how would a modern search engine look like when you start out from the unspecific use-case". What we came up with, is Kuiper.

Compared to a fully specific tryptic search-space, unspecific search-spaces (which produce every possible sub-sequence of the specified length-range), very quickly explode in search-space complexity. A fully unspecific search-space (length 7-52) is almost 900x larger then the tryptic equivalent.

Dear MS Community

For those who did not have the chance to see my ASMS poster about our new search-engine, let me run you through some of the highlights.
Roughly a year ago, due to internal demand from contract research, we started looking into improving our capabilities for unspecific searches.

We have been looking into it for some selected datasets and also more systematically for our AI training data. So far the conclusion was that, while we did not see a lot of it, we were discussing adding a detection and flagging in the final results. But that won't be in the 20.0 release yet.

oh, and forgot to mention. That was directDIA (but Kuiper can also be used to search DDA data as well)

I will be presenting Kuiper (and especially what Spectronaut 20 can do for Immunopeptidomics) at @biognosys.bsky.social breakfast seminar on Tuesday and also at my poster (TP 183)

Really looking forward to Spectronaut 20 release at #ASMS2025. We will be showing our new search-engine Kuiper, purpose built for tackling unspecific search spaces.
It can do an unspecific (peptide length 7-52) open-search in ~30 minutes (2h gradient length Human cell Lysate).

We are happy to announce our latest work as a preprint in proteomics:

Our research showcases significant advancements in DIA on the timsTOF. Through the implementation of diagonal-PASEF and a algorithm in #Spectronaut, we have achieved enhanced peptide identification and precision in human cells.

When I joined Biognosys in 2011 as part of my master thesis to develop a software for DIA / SWATH data analysis.
Never done any mass-spec before that and my proteomics knowledge was primarily down to what we did on 3D structures during my studies.

But we have exactly that already for years. Okey, it does not ask you to "safe the changes", but it warns you that you have experiments open and anything that is not saved will be lost 😅

And never liked the Skyline approach where I have to save the document as the very first step as often I only want to quickly test something. But maybe a "first time config" wizard on a new installation would be a suitable solution.

Yeah, I noticed only after I posted my response, that the message was already over a year old 🤓.
It's tricky to make auto-SNE storage the default as it requires input from the user where it is safe to store.