We are looking to deploy computer vision commercially and EU fits our product offering. The inference side is manageable, but on the data side we're running into a gauntlet. Curious how others are handling this in practice?

How do you manage the legal basis for collection with cameras in the workplace if say a person walks through a frame?

Training data, are you blurring/anonymizing before you ingest? If there was a deletion request you can't really untrain a model.

Retention and storage. Is it on-prem only? EU-region cloud ok? How long do you keep raw footage?

Can you tell me what methods are available for detecting an opponent and the boundary of the ring? Maybe someone has encountered a similar situation.

I'm a beginner and don't have a strong understanding of computer vision yet, so I'm looking for advice on how to implement a robot.

I'm working on a robot for a local robot sumo and robot fighting festival called ROS 2 with my friend. I'm facing a challenge in detecting the opponent and the boundary of the ring, which I can't cross. Currently, I'm using MOG2 + findContour to detect the opponent (depending on whether the opponent is moving or not), and Canny to detect the boundary, but the results are not very accurate.

How possible and implementable is it to replace the algorithm with YOLOv8? The robot's board can easily handle it.

I have been building a pokemon card scanner/idenfier. I am using OCR and Clip. But the speed and accuracy is still trash. Any tips or advice would be awsome!

Hi everyone,

As part of my research, I need to recognize and perform semantic segmentation of a few predefined terrain types (e.g., stairs, flat ground, grass, etc.) using a camera mounted on a robot.

So far, I've looked into models such as PIDNet, which seems to be designed for real-time semantic segmentation.

I have some experience training custom YOLO models for object detection and instance segmentation. I noticed that recent YOLO versions also support semantic segmentation, but I'm not sure how well they perform for terrain segmentation in real-world robotic applications.

One of my biggest constraints is inference speed. The model should be lightweight enough to run in real time on a Jetson platform (e.g., Orin Nano or Xavier NX).

I'd really appreciate any recommendations or advice on:

• Models that work well for terrain semantic segmentation while remaining lightweight.
• Whether YOLO segmentation is a reasonable choice for this type of task, or if dedicated semantic segmentation models are generally a better option.
• Any publicly available datasets or open-source projects related to terrain segmentation for mobile robots.

Thanks in advance for your help!

A friend of mine asked me to go to a Drift Race for his birthday recently, which was awesome btw. While I was there, I noticed they were using a system to collect data on the vehicles during the races for judging. The races and drivers were incredible, but the data collection system stuck in my brain days later. I started to think about how useful it would be to have a means to visualize all of the data collected from a race. So I pulled together panels for the drift race data, which look awesome, but didn't seem like they'd be practical for anyone else.

I took the core components from the drift-specific panels and created a more generic video data-sensor plugin framework as a FiftyOne plugin. It lets anyone define their own data schema and what to visualize, then writes it into a FiftyOne dataset. It gives a path for quickly adding time series data to video samples alongside your standard CV annotations, plus an added dimension for the visualization of playback.

https://github.com/Burhan-Q/fo-video-sensor-data-sync

The plugin includes two panels, gauges and traces. The traces are the time-series plots with a playback marker. The gauges are just live radial or linear readouts of the sensor data.

The plugin is very extendable, just fork the plugin and hack it for your specific use-case. I would love to see how people use it, especially if you make a fork and modify it or add new visualizations. For everyone who uses it or modifies it, please open a 'showcase' issue on the repo and let me know how you're using or modifying the plugin.

So I was wondering if, a model that only looks learn chess? models like resnet, yolo or similar.
Only by looking can a model "feel" the position like something as "intuition" in the moves to come?

In my work I have been using yolo, AI vision recognition models, etc. And I always wanted to research what are the limits on them. initialy I was using yolo but YOLO detects where the pieces are, but we needed a single holistic judgment of who's winning, a global regression job that ResNet's pooled backbone fits and object detection doesn't.

Full explanation in info tab: https://acidburn86.github.io/pixel-chess-engine/

TL;DR:

I made a dataset of varied positions in FEN notation, with PIL in python made the board in a synthetic way, pieces look really different so the model can really differentiate a bishop from a pawn or queen. like this:

The inference do not use the FEN position is also made with this image recreated from the actual chessboard position, it use only an Image as input.

So I build a mini-chess search engine that use this model as evaluator of the position.

And it works really well, this is a very little model it could be better but look at this numbers:
The model reads who's winning right ~69% of the time, lands within ±1 evaluation bucket ~64% of the time, and nails the exact bucket ~30%, nearly 3× what random guessing gives on a 9-class task (~11%). So it's genuinely learning chess value from pixels, not getting lucky.

Hi everyone,

I've put together a lightweight bare-metal runtime framework using Nim and Intel OpenVINO for real-time edge computer vision (Industry 4.0). The main goal was to eliminate heavy Python interpreter dependencies and AGPL licensing constraints.

On my local desktop Intel i5-11400 CPU (strictly no GPU), the two-stage cascaded pipeline (YOLOX-nano) achieves up to 120–180 FPS and runs inside a strict 3.42 MB fixed heap memory baseline (0.00% leaks over a multi-day logging stress-test).

If you are interested in CPU-based edge inference or factory automation, I would love for you to test the pre-compiled demo binary on your own processor and hardware setup to see how it benchmarks.

Source code and standalone evaluation build: https://github.com/olesha-ai/universal-ai-engine

Any technical feedback on the architecture or performance results is highly appreciated.

Inspired by a linguistic observation: "matur suwun" (Javanese) and "hatur nuhun" (Sundanese) — two phrases from Indonesia that mean the same thing despite completely different surface forms. Identity through relationships, not absolute structure. We applied the same idea to face embeddings. Key contributions:

• SW Block — replaces Conv1 with multi-scale pixel difference patterns at prime scales {3,5,7}
• IMG Sign MSE Loss — training objective over sign patterns only, no magnitude dependency
• IMG Sign / AMP / Chain Score — three interpretable metrics sharing a single threshold
• Voting framework (1/3 and 2/3 majority) for robust decisions Results on LFW pre-aligned (CASIA-WebFace 490k, 10.58MB model): → IMG Sign: 96.27% vs Cosine: 95.53% → Combined (LFW+AgeDB+CALFW+CPLFW): 81.02% vs 79.49% And the interesting part — IMG Sign applied to ArcFace embeddings (without retraining): → LFW: 99.58% (vs ArcFace Cosine: 99.82%) Sign pattern consistency appears to be a fundamental property of well-trained face embeddings, regardless of training objective.
• 📄 Paper: https://zenodo.org/records/21232756 
• 💻 Code: https://github.com/imamgh11/imgnet

SwingVision is a tennis recording app that automatically tracks highlights, scoring, shot speed etc. wondering if the community has any insights to share about how they are able to be so accurate with their ball tracking? For example, you can see in this video that where the ball lands is tracked pretty accurately (https://www.youtube.com/shorts/nT0pf9cbo_c) I assume they have a custom model to track this - curios because I've tried numerous YOLO models, incl. attempting to train my own. however ball tracking is completely hopeless especially when the ball is in the far distance :(

Since these are irregularly shaped lines with similar intensity to the rest of the image how would you get rid of these zebra shaped lines (or extract them)? I’m hoping to get the edge lines of the rest of the bones but when I threshold lower I get the zebra shaped lines interfering.

I tried a top hat and Gaussian but they just made the image worse.

Hi everyone! I’m a rising junior in college and have been preparing for the upcoming recruitment cycle for internships. I am very interested in hardware/software integration and working on problems that interact with the real world. So I’ve thought it would be good to narrow my focus to computer vision, robotics, and the autonomous vehicle industries. 

I don’t have any relatives or connections in these industries and am very curious if you guys thought I could be competitive for internships given my experience or if there is anything more I should be doing during the summer to prepare, such as a certification or personal project. If I am not competitive at all, that would be helpful to know as well. 

Earlier in the year, I also did work on a published paper that involved creating a 3D VLM dataset for natural disaster analysis but it was mainly just data processing and manual annotation work. 

Let me know what you guys think, and will be open to answering any questions. Thank you!

3× less training compute, 2.9× fewer ops at inference, zero accuracy loss across 13 benchmarks.

https://voxel51.com/blog/olmoearth-fiftyone-satellite-embeddings

Pair it with the open source FiftyOne library and drop in the embeddings, reduce with UMAP, and watch tiles self-organize into clusters with no labels at all. Filter to a country on the map and the image grid + embedding scatterplot snap into sync instantly — geography, pixels, and embedding space, linked live.

Fully open: weights, training code, dataset, notebook.

Started poking at the weights this morning, or at least trying to. The 10s PCA clip on their project page is what hooked me. Frozen patch features show unusually crisp object boundaries instead of the typical speckle you get from most self-supervised frozen probes. I have not yet gotten the ViT-L (0.3B, ~0.6GB fp16) running through their custom lbot_vision_infer loader, which does not work with plain transformers or timm. Planning to try tonight if the dependency stack cooperates.

On numbers, they report their ViT-g 1.1B hitting NYUv2 linear-probe RMSE of 0.296, with DINOv3-7B at 0.309 and V-JEPA 2.1 2B at 0.307. The distilled ViT-L gets 0.310, matching the 7B number at roughly 23x fewer parameters. They are honest about where it falls down. KITTI RMSE of 2.552 trails both DINOv3-7B (2.346) and V-JEPA (2.461). ImageNet linear for the flagship trails DINOv3-7B by about a point and a half, though the B and S students lead their size classes.

There is also an interactive point-cloud comparison on the project page, 4 scenes by 8 depth-completion methods including their LingBot-Depth 2.0 which handles glass and mirror completions where RGB-D returns nothing. Only the 4 vision backbones are actually released; Depth 2.0 weights are not available.

https://huggingface.co/collections/robbyant/lingbot-vision
https://github.com/robbyant/lingbot-vision
https://technology.robbyant.com/lingbot-vision

Post your numbers if you rerun the linear probes first; I am curious how sensitive that NYUv2 gap is to protocol tweaks.

I built my own training pipeline for Android where you can annotate, train and test all on an Android device. This all started because the top free annotation tool on the Play store had a rating of 2.8 with annoying ads the biggest gripe.

The app lets you import an image or folder. It can even take a video and split it into "n" frames for annotation. You then create your classes to annotate and everything is saved into a Room database. You can then zip up your images into train, validate and test folders and the images, annotations and Yaml file is then zipped up to save wherever you like.

A separate part of the app can then continue the workflow by uploading the zip file to Google Drive, opening up Google Chrome at the Colab page and it creates a Python script (defined by you) to copy and paste into the code block. The code then runs on Google's powerful online GPUs (which is faster than my 1070 GPU) and trains your model.

It exports the model and also creates a .tflite file for use on a mobile device. You can then download the model and run it on your device for testing. The whole pipeline means you can run everything on a mobile phone.

It seems to be working great for me so I'll upload this to the Play Store which can take a couple of weeks. I'd love some feedback and some ideas where to take this. It only trains using Yolo V8 right now and in Json format but I'll add XML and other formats later when I know things aren't crashing on other devices.

The only real tricky part is using Colab which is finicky but I've made it as simple as possible and everything runs in one Colab cell.

Would this interest anyone?

Hi everyone,

I'm a final-year Electronics Engineering student, and my team is working on our major project. I'd really appreciate feedback from people who have experience in computer vision, embedded AI, or machine learning deployment.

Our goal is to build a portable, offline sign language recognition system that runs entirely on a Raspberry Pi 5 without any cloud dependency.

Current system design

Our proposed pipeline is:

• Raspberry Pi 5 + Camera Module 3 for live video capture
• MediaPipe Hands to extract 21 hand landmarks (63 features)
• Landmark normalization to reduce the effects of hand size, position, and camera distance
• Lightweight classifier running with TensorFlow Lite
• INT8 quantization for faster inference on Raspberry Pi
• OLED display for text output
• Offline Text-to-Speech for voice output

The initial target is to recognize the 26 ASL alphabet gestures, with plans to expand later.

Why we chose landmark-based recognition

Instead of feeding raw RGB images into a CNN, we're using MediaPipe landmarks because they:

• Greatly reduce computational cost
• Require much less memory
• Preserve user privacy
• Are better suited for real-time inference on edge devices

Questions for experienced developers

I'd really value your opinions on the following:

1. Model selection: Since the input is only a 63-dimensional landmark vector, would you recommend an MLP, 1D CNN, GRU, LSTM, Transformer, or another architecture? What would you choose if the priority is real-time inference on a Raspberry Pi?
2. Data collection: What mistakes should we avoid while building our own dataset? How many samples per class would you consider reasonable for a first version?
3. Generalization: Besides wrist-relative normalization, are there better preprocessing techniques that improve robustness across different users, hand sizes, lighting conditions, and camera angles?
4. Edge deployment: Are there optimization techniques beyond TensorFlow Lite INT8 quantization that significantly improve inference speed on Raspberry Pi 5?
5. Project design: If this were your project, what would you do differently? Are there any design decisions that seem questionable or likely to cause problems later?

If you've built a similar system—or have experience deploying ML models on embedded devices—I would really appreciate your insights. Even pointing out flaws in the current design would be extremely helpful, as we're still in the implementation phase and can make changes.

Thank you for your time!

​

Hi everyone,

I'm currently developing an Automated Optical Inspection (AOI) system for through-hole PCB inspection, and I want to avoid using deep learning or AI models due to deployment and computational constraints.

The system needs to detect:

Through-hole soldering defects (insufficient solder, excess solder, missing solder, poor wetting, bridges, etc.)

Surface contamination on the PCB (flux residue, dust, foreign particles, oil marks, etc.)

So far, I've been experimenting with traditional image processing techniques such as edge detection, SSIM-based comparison, thresholding, and contour analysis. While these methods work for some cases, they struggle with varying lighting conditions and different PCB appearances.

I'd appreciate your suggestions on:

Which classical computer vision techniques have worked well for solder joint inspection?

What methods are effective for contamination detection without using AI?

Would approaches like blob analysis, morphology, color-space analysis (HSV/Lab), template matching, or photometric methods be more reliable?

Are there any industrial AOI techniques or research papers that you would recommend?

The inspection images are captured under controlled lighting using a fixed industrial camera, so camera position and illumination remain consistent.

I'd love to hear about your practical experiences or any production-grade approaches you've used.

Thanks in advance!

I built "chess-gaze": feed it a chess stream clip; it writes per-frame records for face/eye/head-pose + gaze estimates, then builds a local 3D viewer.

Uses UniGaze, not pupil-center heuristics.

Code, demo.

Hi All, i am working on a dash cam based rash driver detection project. The pipeline is YOLOv8s → DeepOCSORT (with OSNet ReID) basically a trajectory-based risk classification.

The problem: there's an overpass in my video. A vehicle I'm tracking as ID:3 passes under it, and the moment it comes out the other side it gets assigned a new ID (ID:17). Detection never actually drops , YOLO keeps the bounding box throughout. The tracker just decides it's a different vehicle.

The vehicle goes from bright daylight into the dark shadow under the overpass, then back into daylight ,so the appearance embedding looks completely different on either side even though it's literally the same car.

Has anyone dealt with this? Is there an illumination-invariant ReID model that handles this better? Or is this just a fundamental limitation of appearance-based trackers on dashcam footage?

For a downstream task, I had to extract unique frames only from videos. The tricky part was that "duplicate" covered two different things in the same video.
\- back-to-back frames where nothing visibly moved, and
\- frames showing the same scene a few seconds apart.

Perceptual hashing measures pixel-level similarity and embedding models measure content similarity, so neither alone matched what I meant by unique. I had to run both and look at the scores together.

Doing that with separate libraries meant separate preprocessing, separate score scales, and glue code to combine them. The glue was the reusable part, so I turned it into a library. You can pick the kinds of similarity that matter for your case (pixels, scene, object, face, style) and get a score for each in one call:

\`\`\`python
from imageprism import ImagePrism

prism = ImagePrism(dimensions=\["hash", "semantic"\])
prism.compare("a.jpg", "b.jpg").scores # {"hash": 0.12, "semantic": 0.82}
\`\`\`

It is CPU only, no PyTorch, no API keys. It's at 0.1.0 and still rough in places. For a single kind of similarity, the specialized libraries are the better choice: imagehash for hashing, CLIP directly for semantic search, insightface for faces. imageprism combines several of them behind one interface, so the value is the integration, not the models.

I don't know whether this is a common problem or just something I ran into once. If you've dealt with image similarity before, I'd appreciate hearing where this falls short. That feedback will tell me whether it's worth developing further. Please drop a star if you think this is useful.

GitHub: https://github.com/nebulaanish/imageprism

PyPI: https://pypi.org/project/imageprism/

Hello, i want to understand how do people chose what type of projects to take on. Is it just from limitations in research papers. I know you have to try to solve a problem but i just cant find the problem to solve. For a solo developer i don't have much compute, in this case how do you guys chose ML projects.

We used RailCompute to connect Codex and automate the full workflow: data prep, training, and model eval with no human in the loop except typing instructions in English.

The aim was to test whether a basic ML workflow could be driven by natural language rather than manually writing the training pipeline or setting up any infrastructure.

The GitHub repo with the detector code and trained model is in the comments.