DINOv2, SALAD, SuperGlue, and the Dustbin Question
January 17, 2024

This note compares DINOv2/SALAD, SuperGlue, and LightGlue through one implementation question: what happens to unmatched features.

SuperGlue used an optimal-transport dustbin mechanism for unmatched keypoints. The note asks whether a related visual-place-recognition pipeline can remove or change that dustbin step in the way LightGlue did.

Vision-model noteOriginally posted 2024-01-17; expanded here around the dustbin mechanism.

Related: Four-Layer Tiny Transformer Training Run

Article focus: DINOv2/SALAD, SuperGlue, LightGlue, optimal transport, dustbin handling, and visual place recognition.

The Question

Visual matching systems need a way to represent features that should not be matched. In SuperGlue, the dustbin gives the optimal-transport assignment a place to put unmatched keypoints.

The question raised here is whether DINOv2/SALAD-style visual place recognition needs the same mechanism, or whether the pipeline can be simplified in the direction shown by LightGlue.

Why It Matters

Retriever/matcher systems are not only about the embedding backbone. The matching rule decides how ambiguity, missing features, repeated texture, and non-correspondence are represented.

Changing the dustbin is therefore an architectural question: it affects what the model can decline to match, what it is forced to explain, and how much matching machinery remains after the descriptor stage.

Links From the Original Post