Filtlong: The Long-Read Filter That Lets Short Reads Decide What Is Real
A small C++ tool with a big idea: score noisy Nanopore and PacBio reads against length, quality, and optional reference evidence, then keep the parts most likely to help assembly.
- Filtlong ranks long reads by evidence, not just by raw quality thresholds.
- When a reference is available, it turns short reads or an assembly into a fast biological truth set.
- Its scoring and trimming logic let a single noisy read become useful fragments instead of a binary pass or fail.
- The tool feels mature because it solves one sharp problem with a small, practical interface.
Why Filtlong Treats Reads as Evidence, Not Just Strings
Most long-read QC tools start with a blunt question: is this read good enough to keep? Filtlong asks a better one: which parts of this read are real enough to help an assembler? That shift matters because Nanopore and PacBio data can be long, noisy, and uneven in ways that make simple pass or fail filters wasteful.
Filtlong is a tool for filtering long reads by quality. It can take a set of long reads and produce a smaller, better subset. It uses both read length (longer is better) and read identity (higher is better) when choosing which reads pass the filter.
That README line gets to the heart of the project. Filtlong is not trying to be clever for its own sake. It is trying to make a better subset for assembly by mixing long-read utility with a more grounded notion of support.
How Filtlong Decides What to Keep
Under the hood, Filtlong combines several signals. Length matters because longer reads can bridge repeats. Mean quality matters because noisy reads can contaminate assembly. Window quality matters because a read can be mostly fine while hiding a disastrous stretch in the middle.
That design is why it feels more like triage than thresholding. A read does not need to be perfect to survive. It only needs to contribute enough useful sequence to be worth keeping.
filtlong --min_length 1000 --keep_percent 90 reads.fastq.gz > filtered.fastq
filtlong --target_bases 500000000 --trim --split reads.fastq.gz > cleaned.fastqThe CLI stays compact because the mental model stays compact. You decide how much data you want, how strict the selection should be, and whether you want Filtlong to salvage good sequence from bad reads.
The Trick Under the Hood: Bloom Filters for Reference Matching
The most interesting mode is reference-aware filtering. When short reads or an assembly are available, Filtlong can treat them as an external truth set. It does that with a Bloom filter of 16-mers, which gives it a fast, memory-light way to ask whether a short DNA word is supported by the reference.
The point is not exact alignment. The point is a probabilistic shortcut that is good enough for ranking and trimming. Filtlong asks whether enough k-mers are present to treat a region as biologically credible, then uses that evidence to boost or downweight the read.
That is why the fallback mode matters too. Without a reference, Filtlong still works from read quality and length. With a reference, it becomes sharper.
Trimming, Splitting, and the Child-Read Pattern
Filtlong does not always treat a bad read as a lost cause. If one section is strong and another is weak, it can trim the bad section or split the read and keep the better fragments as child reads. That is a more intelligent outcome than deleting the whole record.
This matters most for chimeric or partially degraded reads. A single long molecule can contain enough useful sequence to matter, but only if the tool is willing to separate signal from junk. Filtlong is built for that kind of salvage.
In other words, the unit of value is not always the whole read. Sometimes the useful thing is the surviving segment.
Why the CLI Feels Built by Someone Who Actually Uses It
There is craft in the small details. Filtlong accepts suffixes like 500mb or 1.5g, which fits how bioinformaticians think about scale. You can feel that the interface was shaped by real pipelines, not by abstract product thinking.
If you have very deep reads, definitely do some sort of QC/subsampling to bring them down to a more reasonable depth (~50-100×) before assembly. This will not just save assembly time but probably also give you better assemblies.
That advice is pragmatic. It also explains why Filtlong has a clear role in pipelines: it is not for every dataset, but it is very good when the input is too deep, too uneven, or too noisy to feed directly into assembly.
Filtlong vs. Simpler Read Filters
Filtlong does not replace every other read filter. It solves a narrower, more interesting problem: pick the most useful reads, or the most useful parts of reads, based on multiple signals. Simpler tools are still useful when the goal is just a quick gate or a random downsample.
| Tool | Input signal | Decision style | Reference aware | Trims or splits |
|---|---|---|---|---|
| Filtlong | Length, mean quality, window quality, optional reference support | Ranks reads and salvages useful parts | Yes | Yes |
| Chopper | Length and qscore thresholds | Pass or fail filtering | No | No |
| Rasusa | Target depth only | Random subsampling | No | No |
| fastplong | Quality and adapter-like cleanup | Hybrid cleanup workflow | Usually no | Sometimes |
That table is the real comparison story. Filtlong is not the fastest knife. It is the one that makes a judgment call.
What Makes Filtlong Feel Mature
The project has a narrow surface area, a clear mission, and a stable place in long-read workflows. The codebase is small, the C++ is focused, and the behavior is consistent with how working bioinformaticians actually process data.
That is often what maturity looks like in open source. Not breadth. Precision.
