- server: lock globale matcher (race nel threadpool FastAPI), LRU su
_IMG_CACHE e _RECIPE_MATCHERS (leak), clamp ROI in tutti gli endpoint
(400/422 invece di crash 500, check train senza varianti),
filtro_fp=off disabilita davvero il verify NCC, fallback FILTRO_FP_MAP
= medio, verify_threshold ricetta allineato a 0.4, _draw_matches su
crop locale (era warp+Sobel full-frame per ogni match), spread_radius
default 5->4
- gui: centro overlay edge (W-1)/2 -> W/2 (coerenza col train),
spread_radius 5->4
- matcher legacy: _angle_list include estremo, cap candidati top-level,
save/load persiste template_gray
- auto_tune: ref centrato fuori dal loop angoli
- test_suite: check imread con errore chiaro
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Due ottimizzazioni chiave:
1. Spread bitmap uint8 invece di response map (N_BINS, H, W) float32
- 32x meno memoria, cache-friendly
- Nuovi kernel Numba: _jit_score_bitmap, _jit_popcount_density
- Formato: spread[y,x] bit b = bin b attivo nel raggio di spread
- _refine_angle usa slicing su bitmap con mask & bit
2. Pre-NMS prima di refine_angle/verify_ncc
- Problema: loop 'for raw in candidati' applicava refine+verify A OGNI
candidato prima del check NMS → 2000+ refine chiamati per ~25 match
- Fix: pre-NMS su (cx, cy) subpixel, limita a max_matches*3 candidati,
poi refine + verify solo su quelli
- Esempio worst case: lama_full_fast 55.9s → 1.13s (49x)
Benchmark suite 16 scenari (4 immagini x full/part x fast/preciso):
prima: totale find 94.6s
dopo: totale find 27.3s (3.5x globale)
casi peggiori <5s (prima erano >50s)
ROI parziali (solo metà oggetto) funzionano in tutti i casi.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adriano