DustPort — limit-clipping denoiser in the philosophy of Steady's DustV5 (2003)

[shurik_pronkin]

DustPort 1.0.0

A limit-clipping spatiotemporal denoiser for AviSynth+, in the philosophy of Steady's DustV5 (2003).

GitHub repository (https://github.com/schpuppa-art/dustport-avisynth-) | Releases (download the DLL) (https://github.com/schpuppa-art/dustport-avisynth-/releases/tag/v1.0)

What it does

DustPort reconstructs the four classic Dust modes (FaeryDust / PixieDust / GoldDust / SpaceDust) with modern extensions. The defining property is limit-clipping: every output pixel is guaranteed within source ± limit. No drift, no hallucinated detail, bounded deviation by construction.

This is well-suited for film restoration where modern denoisers (BM3D, KNLMeansCL) sometimes produce plausible-but-wrong output indistinguishable from real detail. DustPort cannot do this architecturally.

Features


Four classic filter names: FaeryDustPort, PixieDustPort, GoldDustPort, SpaceDustPort
Temporal radius tr 1 to 5
Mean or median temporal aggregation (SSE2/SSE4.1 sorting networks)
External motion compensation via prev / next clip arrays (compose with MVTools)
Edge-aware per-pixel limit map (Sobel-based)
Planar YUV support: 8, 10, 12, 14, 16 bit
Per-plane processing via planes parameter
YUY2 legacy support (8-bit, no edge-aware)


Quick example


LoadPlugin("DustPort.dll")

src = LWLibavVideoSource("clip.mkv").ConvertBits(16)

# Build MC clips with MVTools
sup = src.MSuper(pel=2, sharp=2, hpad=16, vpad=16)
bv1 = sup.MAnalyse(isb=true, delta=1, blksize=8, overlap=4, search=5, truemotion=true)
fv1 = sup.MAnalyse(isb=false, delta=1, blksize=8, overlap=4, search=5, truemotion=true)
p1 = src.MCompensate(sup, bv1, thSAD=300)
n1 = src.MCompensate(sup, fv1, thSAD=300)

src.PixieDustPort(limit=5, prev=[p1], next=[n1])


Or for spatial-only without MC (fastest):


src.SpaceDustPort(limit=6)


Relation to the original DustV5

DustV5.dll by Steady (2003) was a 32-bit MMX filter for AviSynth 2.0.x, YUY2 only, source never published. DustPort is an independent reimplementation based on reverse-engineering of the original binary (via pefile + capstone), the public ReadMe, and doom9 forum discussion.

Confirmed from the 2003 binary:

Faery / Pixie / Gold / Space are one class with a mode selector (0/1/2/3), not separate filters
Spatial-only path (SpaceDust, mode 3) is distinct; the other three share spatiotemporal
Default limits: Faery=2, Pixie=5, Gold=8, Space=6
An undocumented mode parameter overrides the per-name default


DustPort adds: larger temporal radius, median option, external MC, edge-aware limit, 10–16 bit planar support. DustPort is not bit-exact with the original; it reproduces the philosophy.

Requirements


AviSynth+ 3.4 or newer
Windows x86-64
CPU with SSE4.1 support (effectively any x64 CPU from 2008 onward)


Feedback

Parameter tuning advice, bug reports, and feature suggestions are welcome in this thread or as GitHub issues. Particularly interested in hearing about behaviour on genuinely noisy restoration material — the test footage I used has relatively clean sources with only synthetic grain on top.

Credits

Original DustV5 (C) 2003 Steady. DustPort is an independent implementation inspired by the same approach.

Released under MIT license.

[Selur]

Thanks!
Vapoursynth support would be nice.

Cu Selur

[Reel.Deel]

Thank you, this is an unexpected port for sure :)

I remember seeing Dust in the old iip script (https://forum.doom9.org/showthread.php?threadid=70916) but never tried due to the plugin being for Avisynth 2.0

[tormento]

DustPort 1.0.0
Thank you!

Could you please tell me more about the algorithm behind this noise reduction plugin? What are the benefits compared to some modern ones such as BM3D?

[StainlessS]

What are the benefits compared to some modern ones such as BM3D?

I imagine a main benefit would be that it was written to run on eg Pentium 3.
(and also that script functions that relied on it, can now be used again)

I think I used to like PixieDust. (avs ~ v2.57 / v2.58)

[DTL]

"bv1 = sup.MAnalyse(isb=true, delta=1, blksize=8, overlap=4, search=5, truemotion=true)"

search=5 may be faster at the beginning of 21 century but its quality may be visibly lower in comparison with 2,3,4.

[shurik_pronkin]

Vapoursynth support would be nice.

Thanks Selur! VapourSynth port is on the radar but not immediate — the current codebase is a single .cpp with AviSynth+ API calls throughout, so it would need a proper abstraction layer or a clean rewrite against the VS API.

If someone from the VS community wants to take a crack at it, the code is MIT-licensed and the algorithm is fully documented in ALGORITHM.md (https://github.com/schpuppa-art/dustport-avisynth-/blob/main/DustPort_build/ALGORITHM.md) on GitHub. The core kernels (temporal mean/median, spatial blend, limit-clipping, Sobel edge map) are pure SSE2/SSE4.1 and don't depend on the AviSynth API at all — they could be lifted into a VS plugin with minimal changes.

[shurik_pronkin]

I remember seeing Dust in the old iip script but never tried due to the plugin being for Avisynth 2.0

Yes, the original DustV5 was stuck on AviSynth 2.0.x / YUY2 only — that was the main reason it fell out of use. Even LoadPluginEx2 couldn't fully bridge it into modern AVS+.

DustPort should be a drop-in philosophical replacement. If you have old scripts that used PixieDust or GoldDust, the wrapper names are the same (with "Port" suffix) and the default limits match the originals. The main visible difference is that DustPort works in planar YUV at any bit depth, so no more ConvertToYUY2 round-trips.

[shurik_pronkin]

Could you please tell me more about the algorithm behind this noise reduction plugin? What are the benefits compared to some modern ones such as BM3D?

Good question. The short version:

DustPort and BM3D solve different problems with different guarantees.

BM3D finds similar patches across the frame, groups them into 3D stacks, applies transform-domain shrinkage (DCT/wavelet), and reconstructs. It's mathematically optimal for additive white Gaussian noise — nothing beats it on PSNR for that noise model. But:

It can hallucinate texture in flat areas (the collaborative filter "invents" detail from similar patches elsewhere)
On non-Gaussian noise (film grain, scan artifacts, compression residue) it can produce plausible-but-wrong output
No bounded guarantee — a pixel can move arbitrarily far from source


DustPort does something much simpler: temporal mean or median over motion-compensated frames, spatial 3x3 weighted blend, then hard-clamp the result to source ± limit. The guarantee is:

Every output pixel is provably within limit units of the source
No hallucinated detail — the filter can only average or select from real pixel values
Predictable, tunable, no black-box behaviour


The trade-off: BM3D produces cleaner-looking output on clean sources. DustPort produces output you can trust — nothing in the result is more than limit away from what the camera captured. For film restoration where you need to preserve the integrity of the original, that matters more than PSNR.

For a deeper look: ALGORITHM.md (https://github.com/schpuppa-art/dustport-avisynth-/blob/main/DustPort_build/ALGORITHM.md)

[shurik_pronkin]

I imagine a main benefit would be that it was written to run on eg Pentium 3.
(and also that script functions that relied on it, can now be used again)

I think I used to like PixieDust. (avs ~ v2.57 / v2.58)

The original DustV5 did use MMX/ISSE, so Pentium III was the floor. )) DustPort requires SSE4.1 minimum (for 16-bit unsigned min/max), so the floor is now circa 2008 (Penryn). Still runs on anything remotely modern.

Good to hear you used PixieDust back in the day. The default limit=5 in PixieDustPort matches the original exactly — that came straight from the binary (reverse-engineered the factory function, each one pushes a different default limit onto the stack before calling the shared constructor).

And yes — old scripts that called Dust through helper .avsi wrappers (like the iip chain Reel.Deel mentioned) can now be revived. Just swap the filter names and drop the ConvertToYUY2 requirement.

[shurik_pronkin]

search=5 may be faster at the beginning of 21 century but its quality may be visibly lower in comparison with 2,3,4.

Fair point. search=5 (full exhaustive) in the README example was chosen for maximum MC quality in a "recommended settings" context, not for speed. For real-world use I've been running search=4 (hexagon) with no visible quality loss on my material.

In practice, the MVTools settings in the example are meant as a starting point — pel, blksize, overlap, and search should all be tuned to the source. For slower material (classic cinema, TV archive) you can go quite aggressive:


sup = src.MSuper(pel=1, sharp=0, hpad=8, vpad=8)
bv1 = sup.MAnalyse(isb=true, delta=1, blksize=16, overlap=0, search=4, truemotion=true)


This gave me ~4.4x speedup over the original example with no visible degradation on my test footage. I'll update the README to note this — thanks for the catch.

[Boulder]

"bv1 = sup.MAnalyse(isb=true, delta=1, blksize=8, overlap=4, search=5, truemotion=true)"

search=5 may be faster at the beginning of 21 century but its quality may be visibly lower in comparison with 2,3,4.

I think search=5 is slower than 4. 3 is the slowest, being exhaustive.

I really don't believe anyone will see a difference between the modes during playback once the denoiser *and* the encoder have hammered the source.