Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Optical tracker: frames without a marker run detection twice since the #53 full-resolution retry

Aperta
  • Qualcosa non va?
#91 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
computer-vision, performance

Direzione di ricerca

Start in WebARKitTracker.cpp around lines 409-428 in WebARKitTracker::processFrame, where the full-resolution retry follows detectAndMatch, then read MatchFeatures for the minNumMatches check. Choose a retry policy (immediate on partial signal, rate-limited otherwise, or a config flag) and agree it with maintainers first. Done means the no-marker path no longer runs both passes every frame, a regression test or timing check covers it, and the #53 small-marker detection test still passes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

C/C++ code enhancement

Description

Since #64 (fix for #53), WebARKitTracker::processFrame runs detectAndMatch on the downsampled frame and, when that does not detect a marker and _featureDetectPyrLevel > 0, retries at full resolution (WebARKitTracker.cpp ~409-428). The retry is gated on match failure, so with no marker in view it fires on every detection frame: each frame pays feature extraction and kNN matching on the pyramid frame and on the full frame. While searching, that is more expensive than the full-resolution-only path before #44 introduced downsampling.

The code comment acknowledges it ("the extra full-res pass only costs while NOT detected"). With a webcam, the "not detected" state is common: the camera points away, the marker leaves the view, tracking is lost. Raised by Qodo on the 0.10.1 release PR #90.

Proposal

Keep the immediate retry when the pyramid pass shows a signal, and rate-limit it otherwise. For example:

  • retry at once when the pyramid pass produced a partial signal (ratio-test survivors > 0 but < minNumMatches, or a RANSAC fit that failed validation);
  • after passes with no signal, retry at full resolution only every N frames, or alternate pyramid and full-resolution passes;
  • or expose a config flag to disable the retry.

A regression test, or a timing harness, should cover the "no marker in view" path, and the #53 small-marker case must still be detected.

Related: the minNumMatches floor (also from #64)

#64 also made MatchFeatures honour minNumMatches for the first time (it was assigned per tracker but never read): homography estimation now needs at least 15 ratio-test survivors for AKAZE, FREAK and the default tracker. Before, a frame with 8–14 good matches still reached homography validation and could be accepted. This is a deliberate trade-off (fewer spurious homographies, aligned with OCVT's defaults), not a bug, but it can miss weakly matched markers. Worth revisiting with real-world data together with the retry policy, since both decide what a "failed" detection frame is.

Lingua principale
C++
Stelle
21
Fork
8
Merge medio
6h 49m
PR unite (30g)
29

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webarkit/WebARKitLib

Tutte le issue di webarkit/WebARKitLib

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.