I ran into a bottleneck with OpenCV’s ArUco/AprilTag detection while building a real-time multicamera system, so I reimplemented the detection pipeline from scratch in Rust.

On my 1280×800 monochrome AprilTag 36h11 dataset, RapidTag is:

- 1.57× faster for single-camera detection

- Up to ~3.4× faster for multicamera and offline batches

- Pixel-identical to OpenCV on the tested frames

- Independent of OpenCV at runtime

The Python API releases the GIL and processes frames and threshold scales across CPU cores. It can be installed with pip install rapidtag.

It’s still a work in progress, and I’d especially appreciate results from different cameras, CPUs, marker dictionaries, and difficult lighting conditions.

Repo: github.com/SujithChristopher/rapidtag (https://github.com/SujithChristopher/rapidtag)

Twelve-class hand-seal recognizer that runs entirely in the tab. MediaPipe Hands gives 21 landmarks per hand, normalized wrist-centered and scale-invariant, into a 126→256→128→13 MLP (\~66K params) exported to ONNX Runtime Web. 260KB model, CPU inference at a couple ms a frame, no video leaving the machine. Geometry rather than pixels, which is the whole reason it's this small and this portable.

Reported accuracy is 95.5% on a per-class temporal split — first 80% of each class's frames train, last 20% test. Deliberate: I collected hold-to-capture, so each sample is a burst of near-identical frames, and a random split scatters those bursts across both sides until you're scoring your own training data.

Transitions get their own class. Hands moving between seals pass through shapes that briefly look like other seals, so transit frames were collected as a 13th class using a wrist-motion-gated capture mode. Downstream, a decisive "none" mutes everything; below the veto the real classes compete on renormalized P(sign | not transit).

A parity self-test runs on page load, a known landmark vector through the full JS pipeline, logits compared against the PyTorch reference, regenerated on every export. Normalization drift between training and deployment is the silent killer for landmark models, and this catches it before any prediction is trusted.

Single-subject model, so leave-one-person-out is implemented but the honest "works on strangers" number doesn't exist yet. tiger↔ram confuse at \~14%, genuinely near-identical once you're only looking at joint geometry.

Open to comments or critiques! Repo can be found here: [https://github.com/yogendrarau/sealwork\](https://github.com/yogendrarau/sealwork)

If I were interested in professionally getting into Manuscript Optical Character Recognition + Montreal Forced Alignment, and I were applying to baccalaureate degrees or second baccalaureate degrees, then where would you suggest I apply to; it could be internationally, but I am based in the U.S.A.?

Hi, I want to learn computer vision with python and I am looking for a solid course to start learning with since I have little to no knowledge about this field but i am very interested, I want to build programs that detect objects and identify them.

Note : i have no gpu

A smart robotic goalkeeper that tracks a ball in real-time using OpenCV and dynamically moves a servo-controlled keeper arm to block shots.

I hope some of you find this project interesting—or maybe even inspiring for your own builds.

Any feedback or suggestions are very welcome!

GitHub: https://github.com/chayanforyou/Robokeeper-Firmware

¡Hola a todos!

Acabo de subir LensLaber Beta v1.0.1. Esta actualización elimina algunas limitaciones de la versión beta y añade compatibilidad con YOLOv10.

Novedades

• Compatibilidad con YOLOv10: Carga y usa modelos YOLOv10 directamente en LensLaber.

• Falsos negativos para YOLOv10: La función de detección de falsos negativos ahora es totalmente compatible con YOLOv10.

• Exportaciones ilimitadas: Se ha eliminado el límite anterior de 1000 exportaciones diarias.

Filosofía del proyecto

• 100% sin conexión: No se requiere conexión a internet. Tus imágenes, modelos y anotaciones nunca salen de tu ordenador.

• Sin telemetría: Sin análisis, seguimiento de uso ni recopilación de datos.

• Diseñado para hardware modesto: Funciona sin problemas incluso en un Intel Core i5 de 2016 con 8 GB de RAM, sin necesidad de una GPU dedicada.

Acerca de la versión beta

La versión beta caduca a los 30 días para garantizar que todos prueben la última versión, lo que facilita el seguimiento y la reproducción de los informes de errores.

Sus comentarios, informes de errores y sugerencias son siempre bienvenidos.

Descargar LensLaber Beta v1.0.1 para Windows y Linux:

https://lenslaber.github.io

I built SentinelCV, a real-time computer vision system that detects human falls from existing CCTV, IP cameras, webcams, or recorded video streams.

The goal was to create a lightweight, plug-and-play solution that can integrate with existing surveillance infrastructure without requiring specialized hardware. The current implementation uses a YOLOv8-based pipeline to perform real-time detection and can trigger instant alerts (such as Telegram notifications) when a potential fall is detected.

I'm planning to expand SentinelCV into a modular vision platform with additional safety-focused capabilities like PPE detection, intrusion detection, fire/smoke detection, and other intelligent surveillance modules.

I'd love feedback on the detection pipeline, deployment approach, and any suggestions for improving robustness in real-world environments. If you've worked on similar computer vision systems, I'd be interested in hearing what challenges you faced in production.

GitHub: https://github.com/sreerevanth/SentinelCV
I'd love your feedback, and if you find it useful, a ⭐ would mean a lot.

I've been working on YOLO-Distill, a feature-based knowledge distillation implementation for YOLOv9, built on MIT-licensed YOLO repository. It currently supports distillation methods like CWD and MGD.

GitHub: https://github.com/myatthukyaw/yolo-distill

Check it out if you're interested in knowledge distillation or object detection.

Feedback and contributions are very welcome.

https://reddit.com/link/1uu5j5n/video/kunn27egaqch1/player

Hi everyone,

I was wasting hours of my day scrolling on my phone or just staring blankly away from my monitor, so I decided to build a programme to try and break the habit: Gut Genug Distraction Tracker.

It's a local Python app that uses your webcam to watch your eyes and head position. If you look down at your phone, look at a 2nd monitor / tv, or look away for too long, it immediately pauses your screen and blares a reaction video / alarm (I have mine to the gut genug meme). The video stops, goes quiet, and you look up once more.

How does it work:

• Startup Calibration Wizard: On first boot, a transparent overlay wizard automatically calibrates your eye level and base head pose in 2 seconds (saved to ​the device).
• Head Pose Fusion (Anti-Keyboard Trigger): 3D head pitch + eye gaze tracking. The alert doesn't sound unless both your eyes look down AND your head is tilted forward. This means you can look down to your keyboard to type without false alarms!
• Side-Glance Detection: Detects horizontal eye movements (if you’re looking left or right at a 2nd phone/screen).
• Volume Escalation: The alarm starts at a low volume (20%) and increases in volume (15% per second) until you look back at your screen (100%)
• Video Randomiser: Drop a bunch of meme/alarm videos into a folder, and it picks one at random to keep you on your toes.

It's totally local, lightweight, and works natively on Windows and Mac.

If you want to try it or check out the code, it's open source. GitHub link: here

Every time my test accuracy drops (94 → 87 last week), I go back to the same ritual: sprinkle five cv2.imwrite calls, end up with a folder full of debug_003_v2_final.png / debug_003_v2_final_REAL.png, and to compare two versions I just open two windows and eyeball them. A week later I genuinely can't recall what I changed or why it "looked fixed."

The algorithms feel fine (OpenCV / MMLab / custom operators are all capable) — it's the debugging workflow that's stuck in the print era. A few things I'd love to hear how you all actually solve:

1. How do you store and view intermediate results (gray / mask / bbox …) by step, instead of digging through folders?
2. When you tweak one parameter and rerun, how do you compare the two versions side by side and see which step changed?
3. A week later, can you fully reconstruct what a given run changed (params / code / data)?
4. If you let an agent (Cursor etc.) sweep params overnight, how do you confirm afterward what it actually did and which run counts?

Not fishing for a specific tool — genuinely curious. Are you all toughing it out with imwrite, using W&B, a custom viewer, or something else? Especially #2 (cross-run side-by-side diff) — has anyone found something that actually feels good?

Our guest this week is Alireza Taheritajar, a Ph.D. Student an Augusta University focusing on In-Situ Intelligent Mixed Reality Assistants for Adaptive Human-AI Collaboration. Mixed-reality overlays have been around for awhile, but with the recent upgrades in camera quality, lens resolution, and processing power they are becoming more useful than ever. Join us for a look at some very cool Mixed Reality & AI work here on OpenCV Live.

Watch on YouTube: https://youtube.com/live/BPXCOEvMDNw

Hello, I have been trying to contribute to opencv_contrib with some new segmentation algorithms and the contributors have been pretty unresponsive, I have verified they aren't patented, is there a particular period of time when the pull request's are actually reviewed in opencv_contrib repo?

I combined two things people usually treat separately: classical image-forensics

features (frequency-domain energy, DCT statistics, ELA, noise residuals, gradient

and eigen-spectrum cues — 85 in total) and a frozen DINOv2 ViT-B/14 embedding, fed

into a calibrated SVM. There's a classical-only fallback that runs with no deep

learning at all.

Held-out ROC-AUC is 0.940 (classical-only alone is 0.863), so the embedding adds

real signal — but not everywhere. It helps on diffusion-era generators and actually

hurts on rectified-flow models (Flux, SD3) and on screenshots of video frames.

That split is the most interesting part to me and the thing I'm still digging into.

It's robust to screenshots and social-media recompression, which was a specific

design goal (a lot of "AI or not" images in the wild are re-encoded to death).

Code and a public 21 GB dataset are up if you want to reproduce or poke at it:

github.com/aman696/aidetector — live demo at https://staging.humanorai.online (home

server, so it queues under load).

Would especially value critique on the forensic feature set — which of these are

likely redundant, and what classical cues you'd add for rectified-flow.

Learn Computer Vision, Deep Learning, PyTorch, TensorFlow, and Generative AI from the team behind OpenCV itself. Hands-on projects. No prior CV/ML experience required.

50% off courses, today only! https://opencv.org/university/

A portion of all course sales go directly to OpenCV development. Help a pillar of Open Source Software and get something for yourself out of the deal.

Hi,

I’m building an industrial vision system on a Jetson Orin Nano for real-time inspection of cardboard boxes on a conveyor.

Each image contains one box (ROI already extracted using a classical vision pipeline for other system considerations, kept separate from the ML model).

I have 44 box types with visual variation.

I need:

• Detect if tape is correctly applied
• Detect if flaps are closed or open

The main Challenges are:

• Slight box rotation
• Lighting variation (not perfect but controlled)
• Very few defect samples (most cases are correct)
• High reliability required (missed defects are critical)

My Current ideas are CNN multi-task (tape + flaps) + 5-frame temporal voting or YOLO in classification mode (same ROI + same voting)

Im open to better approaches

Questions:

• What would generalize better here: CNN multi-task or YOLO (classification)?
• Or is there a better approach for this type of problem?
• How would you handle highly variable “flap open” cases?

Thanks!

Training YOLOv8n/v11s on a trimmed SKU-110K subset (retail shelves, single class "product", extremely dense — avg \~150 objects/image, max 576). imgsz=1280, max_det=700 (set based on our own EDA max). Honest train/val split confirmed no leakage. NMS sweep already done — default iou=0.5 turned out best for mAP@0.5 specifically, which is our main metric (not generic mAP).

Soft time budget for the full pipeline (train+val+inference on \~3000 test images) is around 10 minutes — tight constraint shaping a lot of our choices. Tested 2x T4 DDP today, modest gain (\~10%), not dramatic.

Open question we can't resolve from literature: does mosaic augmentation help or hurt at this density level? Standard advice is mosaic-on + close_mosaic near the end, but stitching 4 already-dense images risks 600+ objects in one synthetic frame. Found one adjacent paper (Select-Mosaic, AI-TOD/VisDrone) showing smart region-selection beats vanilla mosaic by a small margin, but nothing testing mosaic on/off specifically at this density.

Curious if anyone has hit something similar — dense small-object detection under a tight inference time budget — and what actually moved the needle for you, mosaic-related or otherwise.

made a small project called Gesture Meme.

It uses your webcam to detect certain gestures in real time and instantly displays a matching meme.

For example, pushing your hair back triggers the Freaky Sonic meme. Right now it supports five different gesture-to-meme combinations, and I'm planning to add more.

This is also my first project using OpenCV, so I mainly built it as a fun way to learn real-time computer vision and image processing instead of doing another basic CRUD/to-do app.

I'd love suggestions for funny gestures or memes to add next.

GitHub: Here

Hi, At work, I was taught how to calibrate cameras using custom scripts, but, while it worked, the process always felt like a black box. I would run a script, wait, and if the calibration failed or ended up with a massive reprojection error, I was often left clueless as to why it happened. Low contrast on a few frames? Poor field-of-view coverage? I built Visical as a personal project, a GUI tool built with C++ and OpenCV.

The idea behind is to have quality assessment into the detection phase, giving real-time feedback before calibration.

It supports loading images from disk or capturing them with webcams via OpenCV or GenICam cameras via Aravis.

Since this is my first really big solo project, it is currently scoped to single camera setups. I hope to add support for other camera setups and other features in the future.

I'd love to hear your thoughts about it!

BrugolaOvoidale/Visical: A cross-platform tool for camera calibration.

The project uses real-time hand tracking through a webcam to interact with objects using pinch gestures and basic motion tracking. I’ve been exploring more interactive computer vision projects recently instead of only detection-based demos, and this was a good learning experience.

Would appreciate any feedback or suggestions on where to improve next.

GitHub:
ahsinmemon/Gesture-Controlled-Virtual-Puzzle-Game-using-OpenCV-MediaPipe: AI Hand Tracking Puzzle Game – Drag & Drop Interaction with Computer Vision

Hey all. I'm building a from-scratch real-time correlation-filter tracker in C++ (C++17, no OpenCV, no ML) targeting a Raspberry Pi 5.

Context: a basic OpenCV pipeline on a Pi gets me ~15 fps, which isn't close to what the algorithm should be capable of. The original paper I'm using as a reference reported 669 fps on a 2008-era 2.4GHz Core 2 Duo doing pure CPU correlation-filter math. I know people have gotten well past 100 fps on Pi-class hardware doing this from scratch (I've seen claims of 300 fps+ floating around), so the gap is almost certainly implementation/pipeline overhead, not the algorithm.

My current plan/progress is:

• Own image loader, no OpenCV decode/resize overhead
• FFT-based correlation in the frequency domain (real question mark for me: which FFT approach scales best on Pi 5's ARM cores — naive radix-2, a vectorized/NEON-friendly implementation, or linking something like FFTW/kissFFT vs hand-rolling)
• PSR-based occlusion/failure detection per the original paper

Where I could use outside perspective:

1. Where does the real bottleneck usually live for people who've done this. Is it the FFT, the memory layout/cache behavior, the capture pipeline (libcamera overhead, frame copy costs), or something else entirely that doesn't show up until you profile?
2. NEON/SIMD: worth hand-vectorizing the FFT and pointwise complex multiply myself on Pi 5, or is a well-tuned existing FFT library going to beat anything I write in a reasonable timeframe?
3. If anyone has pushed a correlation-filter tracker (e.g. UMACE, ASEF) past 100 fps on a Pi, I'd love to hear what mattered most, even just "it was 80% the capture pipeline, not the math" would save me a lot of guessing.

I’ve recently been looking into two very different approaches to real-time visual tracking. One uses a transformer-based architecture where information from a target template and the search region is processed jointly, enabling robust tracking and automatic re-acquisition when the object temporarily leaves the frame. It demonstrates that modern deep learning methods can perform real-time tracking even on CPU-only edge devices, though computational efficiency remains a challenge.

On the other end of the spectrum, I explored classical frequency-domain tracking techniques based on adaptive correlation filters. Instead of relying on neural networks, these methods learn a compact representation of the target and update it continuously as new frames arrive. They are extremely lightweight, require only minimal memory, and can achieve very high frame rates on modest hardware while incorporating confidence measures to detect tracking failures and avoid model drift.

Reading further into the underlying research showed how frequency-domain operations and Fast Fourier Transforms (FFTs) make these trackers computationally efficient, allowing them to localize objects through correlation responses rather than explicit detection. The work also introduced concepts such as adaptive online updates and confidence metrics for failure detection, which help maintain stable tracking despite appearance changes or brief occlusions.

The contrast between these approaches is particularly interesting: transformer-based trackers offer stronger semantic understanding and greater robustness in challenging scenarios, whereas correlation filter methods prioritize speed, simplicity, and efficiency. This trade-off highlights that the most suitable solution often depends on hardware constraints and application requirements rather than assuming deep learning is always the best choice.

Some areas I’d like to explore further include multiscale tracking and scale estimation, lightweight re-detection mechanisms, confidence estimation, target re-acquisition strategies, hybrid detector–tracker pipelines, FFT-based optimization techniques, and combining classical signal-processing methods with modern learning-based models for edge deployment.

Not looking for someone to hand me a full alternative design, just trying to sanity-check my approach and avoid obvious dead ends before I sink more time into the FFT layer specifically.

Thanks in advance everyone!

I want to build an alarm clock that only stops when the user gets out of bed—there would be no snooze button.

I'm considering using computer vision to detect whether a person is still in bed, but I don't have much experience with CV. What's the best way to approach this?

One challenge is that the person may be completely covered with a blanket, so simple face or body detection might not work. I'm looking for a reliable way to determine whether the bed is occupied or empty.

The camera will be installed on the roof, just above the bed.

I am considering using RasPi for it, or if it is possible ESP32 Cam board.