Computer Vision Engineer (Geometry + Edge ML) — Bullet-Hole Detection on Mobile, 75% → 99%

We have a working Flutter Android app ("GAZELLE SIGHT") that detects bullet holes on paper shooting targets from phone video and scores them into HEAD/BODY zones. A narrow, specialized model already reached ~99% indoors on one target type — but our attempt at a universal model (any target print, any lighting, indoor/outdoor) dropped accuracy badly, with three failure modes: false positives on printed target patterns, "hole-in-a-hole" overlapping shots, and mobile hardware overload. We do not need real-time detection. We're moving to offline post-process: the shooter fires a known number of rounds (e.g. 3), and results can appear ~1 minute after the string. This removes the latency/thermal budget and lets us use heavier, multi-frame methods. Our strategic direction (validated by an expert review): the win is an offline, multi-frame measurement engine — stabilize the video (image registration), difference each frame against a clean pre-fire reference (printed pattern is static; holes appear over time), localize change-events, and use the known shot count for constrained assignment ("find exactly N new holes"). A neural detector (YOLO) and a patch classifier act as verifiers, not as the primary detector. This is primarily a classical/geometric CV + edge-engineering problem; deep learning is a supporting component, not the centerpiece. You will: - Build the offline multi-frame pipeline: ORB/feature homography stabilization (sub-pixel), temporal/reference differencing, change-event clustering, known-N constrained assignment. - Recover small holes (5–13 px at distance) via full-res SAHI-style tiling instead of 640×640 downscaling. - Fix overlapping-shot handling: replace greedy hard-NMS (Soft-NMS / center-distance / temporal time-of-appearance). - Kill print-pattern false positives via reference differencing + hard-negative mining. - Deploy on-device: TFLite/LiteRT, INT8 quantization, delegate selection (XNNPACK/GPU/NNAPI), integrate into the existing Flutter app via FFI. - Keep it on-device (privacy/no-internet); a cloud "oracle" for auto-labeling/validation is welcome, production runs on the phone. Important constraint: No audio shot-detection — we shoot beside adjacent lanes, so audio can't isolate our shots. Solution is vision-only (the camera sees only our own target — an advantage). Current / target stack: Flutter/Dart · native C++ via FFI · OpenCV (ORB homography, CLAHE, contours) · TFLite (YOLOv8 640×640 + MobileNetV3 128×128) · Android/Kotlin/NDK · training in Python + Ultralytics YOLO. Required — must-have (core): - Classical / geometric computer vision: image registration & homography (RANSAC, sub-pixel), video stabilization, temporal differencing / change detection, multi-frame analysis. (This is the #1 skill — the engine lives or dies on registration quality.) - Strong OpenCV in both Python and C++; comfortable working in an FFI codebase. - On-device / edge ML: TFLite/LiteRT conversion + INT8/QAT quantization, delegates (XNNPACK/GPU/NNAPI) and their pitfalls, on-device benchmarking, FFI/isolate memory. Required — important (also essential): - Object detection with Ultralytics YOLO (v8/v11) and/or RT-DETR, incl. small-object detection and SAHI / tiled inference, NMS variants (incl. Soft-NMS). - Training & data engineering: fine-tuning, dataset/labeling, hard-negative mining, augmentation/synthesis, and an eval harness that measures recall/mAP on a held-out set. - Thinks in metrics (recall@IoU, mAP, on-device latency) — not vibes. Supporting: Flutter/Dart + Android (NDK) integration into an existing app. Bonus: knowledge distillation (teacher→student), SLAM/photogrammetry/video-processing background, MLOps / data-flywheel. How we'll work: We start with a small paid trial task on one real clip before the full build — a quick, fair way to see your approach on real footage. If it goes well, we move into the full engagement. Screening questions (answer in your proposal): 1. Our pipeline misses ~25% of hits, fires false positives on the printed target pattern, and can't resolve two shots through the same spot. What's your first move? (Tell us your reasoning.) 2. Holes are 5–13 px at distance but the model runs at 640×640 — how do you avoid losing them? 3. Link a project where you shipped an on-device CV model — with real before/after accuracy or latency numbers. In your proposal, also briefly address: how the known shot count (N) helps accuracy; what you'd do if TFLite conversion cost you 8% mAP; how you'd measure that we reached 99%; and how you ensure only our hits count when shooting beside other lanes. To apply: Share 1–2 relevant projects (with real mAP/recall/latency numbers), your answers above, and your proposed approach.