Leaderboard

Rankings, Metrics & Submissions

Matched public methods receive provisional RbS-Score ranks balancing clean Spring performance and the official additive RobustSpring proxy with equal weight.

Current Standings

RoCo-Spring Leaderboard

Lower RbS-Scores rank higher. Registered teams without a matched public benchmark result appear after scored teams in alphabetical order.

Last updated:

Organizer-published live snapshot

Refresh requests the latest registered-team roster and public Spring/RobustSpring results. Successful results are cached briefly to protect the benchmark service.

The organizer-approved matcher uses an exact RoCo team ID first, then a unique normalized team-name substring. Private or unmatched benchmark entries remain pending instead of being assigned arbitrarily. Automatic matches are provisional: ranked and award-eligible entries must use the same method, checkpoint, inference settings, and clean outputs in both uploads, subject to organizer verification. The public benchmark cannot prove that cross-upload identity. “Spring Submission Time” is the original Spring result time; a separate RobustSpring upload time is not exposed publicly.

Loading published standings…
Metric

RbS-Score

Official 2026 scoring convention: the public RobustSpring tables report clean-to-corrupted prediction disagreement, Δ. For this challenge, the organizers define the additive proxy ER,proxy = ES + Δ. This operational proxy is used consistently for baselines and submissions; it is not presented as an exact corrupted-input ground-truth measurement.

Each quantitative task will be ranked using the Robustness-balanced Spring Score (RbS-Score). The score combines a method's accuracy on the clean Spring benchmark (S) with its additive RobustSpring proxy (R,proxy). Both components receive equal weight, and lower is better.

RbS-Scoret(m) = 0.5 · ESt(m) / BSt + 0.5 · ER,proxyt(m) / BR,proxyt
  • m: the evaluated method.
  • t: the quantitative task, such as Optical Flow, Stereo Matching, or Scene Flow.
  • ESt(m): the method's endpoint-error-style metric on the clean Spring data.
  • ER,proxyt(m): the clean Spring error plus the matching RobustSpring prediction disagreement.
  • BSt, BR,proxyt: fixed task-specific medians from the qualifying Spring-team submissions below.

Each clean baseline is the median of the published clean metrics. Each RobustSpring proxy baseline is the median of the per-method sums ES + Δ; it is not the sum of two independently rounded medians.

Fixed 2026 Baselines

Task Common Methods BS Median Δ BR,proxy
Optical Flow · EPE 8 0.9925 4.160 6.030
Stereo Matching · Abs 4 3.4545 16.180 18.4505

Official tables: Optical Flow accuracy, Optical Flow robustness, Stereo Matching accuracy, and Stereo Matching robustness.

Show every scalar baseline calculation

Optical Flow

Method ES Δ ES + Δ
MS-RAFT+0.6433.6204.263
FlowFormer0.7233.7704.493
FlowNet21.0407.0108.050
RAFT1.4765.6407.116
GMA0.9144.0304.944
GMFlow0.9452.9803.925
SPyNet4.1624.2908.452
PWCNet2.2887.2509.538

Stereo Matching · like-for-like Scene Flow/FlyingThings checkpoints

Method ES Δ ES + Δ
RAFT-Stereo3.02516.57019.595
ACVNet1.51615.79017.306
LEAStereo3.88421.90025.784
GANet4.59412.11016.704

Every listed method occurs in both benchmark papers, has finite values in both official views, and is marked “submitted by Spring team” by the benchmark. Additional task projections and checkpoint variants are not mixed into the paper-to-paper baseline set.

Task-Specific Error Metrics

The same task-specific clean metric is paired with its matching RobustSpring disagreement. The official additive convention is applied component by component.

  • Optical Flow: mean endpoint error (EPE).
  • Stereo Matching: mean absolute disparity error (Abs).
  • Scene Flow: a balanced combination of the errors for reference-frame disparity d1, target-frame disparity d2, and Optical Flow. Each component is normalized by its own baseline error before the three components are averaged:
    RbS-ScoreSF(m) = 0.5 · [ ( Absd1,S(m) / Bd1,S + Absd2,S(m) / Bd2,S + EPEflow,S(m) / Bflow,S ) / 3 ] + 0.5 · [ ( Absd1,R,proxy(m) / Bd1,R,proxy + Absd2,R,proxy(m) / Bd2,R,proxy + EPEflow,R,proxy(m) / Bflow,R,proxy ) / 3 ]
Scene Flow Component BS Median Δ BR,proxy
d1 · Abs 7.466 17.005 24.471
d2 · Abs 7.5935 0.215 7.8085
Flow · EPE 2.527 4.210 6.737

The Scene Flow medians use the two common paper methods, M-FUSE (K) and RAFT-3D (K). All three clean components come from each method's public Scene Flow result page, matching the convention used to score a participant submission. Each component is paired with the disagreement in the same public robustness row. See the official Scene Flow accuracy table, Scene Flow robustness table and the RobustSpring paper.

Show every Scene Flow component calculation
Method Clean d1 Clean d2 Clean Flow Δd1 Δd2 ΔFlow Proxy d1 Proxy d2 Proxy Flow
M-FUSE (K)7.8908.0762.52621.9000.2903.39029.7908.3665.916
RAFT-3D (K)7.0427.1112.52812.1100.1405.03019.1527.2517.558

A score of 1.0 indicates that a method matches them on average. Scores below 1.0 will indicate better normalized performance, while scores above 1.0 will indicate worse normalized performance.

The Cross-Task score is the arithmetic mean of a team's Optical Flow, Stereo Matching, and Scene Flow RbS-Scores. It is published only after the team has a valid result in all three quantitative tasks. When a team has several methods in one task, the most recently submitted complete method is used for that task's Cross-Task component; the task leaderboard continues to show every retained method separately.

Tie-Breaking

If two methods obtain the same RbS-Score, ties are resolved in the following order:

  1. Lower normalized RobustSpring term
  2. Lower normalized Spring term
  3. Lower organizer-issued numeric team ID
  4. Lower immutable numeric Spring result ID when the same team still has an exact tie
Submissions

Submission Workflow

  1. Generate predictions for the selected task
  2. Package archive in the required format
  3. Validate archive locally using the Starter Kit
  4. Submit to the benchmark server using your unique team ID
  5. Check leaderboard for results
Call for Papers

Paper Requirements

Each quantitative or exploration entry must submit a 4–6 page single-blind workshop paper. The paper should describe the method, implementation details, training and pretraining data, compute budget, results, ablations, and limitations.

Papers will be reviewed by the organizers and additional external reviewers with expertise in Optical Flow, Stereo Matching, Scene Flow, robustness, and benchmark design. Acceptance will depend on technical soundness, clarity, reproducibility, and relevance to robust dense correspondence, not only on leaderboard rank. All accepted papers will be forwarded for the official PMLR volume of NeurIPS workshop proceedings.

OpenReview Submission

Reproducibility Package

With the camera-ready deadline, each entry must submit a reproducibility package together with the paper. Award eligibility requires an accepted workshop paper and a complete package that meets the requirements below.

  • Dataset declaration. List every dataset used for training, pretraining, fine-tuning, and validation (not only Spring and RobustSpring).
  • Training scripts. Provide runnable scripts or commands that reproduce training end to end.
  • Evaluation scripts. Provide runnable scripts that reproduce the metrics and results reported in the paper on the declared data splits.
  • Resource requirements. Document hardware and runtime needs for both training and evaluation, including GPU type, GPU count, peak memory, and wall-clock time.
  • README. Include a detailed, concise setup guide that explains how to install dependencies and rerun training and evaluation. Pin the environment either with a pyproject.toml following the Python packaging guide, or with explicit conda instructions that list every library and version required to recreate the environment.