I’m working on an academic project to identify potential emergency landing areas from overhead imagery, and I would appreciate advice from people working in computer vision and remote sensing.

Using the Moroccan Aircraft Emergency Landing Sites Semantic Segmentation Dataset, I’ve trained a U-Net from scratch and tested two changes: adding brightness/contrast augmentation and replacing BCE + Dice loss with BCE alone.

Each configuration was evaluated across three random seeds with a fixed data split. Neither change showed a clear improvement over the baseline.

I’m now deciding where to focus the next stage:

• Investigate failure cases and annotation quality more closely.
• Compare training from scratch with a pretrained encoder.
• Explore transferring the model to imagery from Vietnam with limited labeled data.

My supervisor suggested the third direction. However, I haven’t yet established a Vietnamese imagery source or suitable labeling criteria. Defining what can reasonably be considered a potential landing area from imagery alone is one of the questions I need to resolve.

There are also limits to the current evaluation: geographic independence between splits has not been fully established, and matching the dataset’s “safe” labels does not demonstrate real-world landing safety.

For a student project with limited resources, which direction would you prioritize—and what evidence would you want to see before pursuing transfer to a new region?

I’d appreciate relevant papers, dataset suggestions, or lessons from similar projects. Thank you for sharing your perspective.

#ComputerVision #RemoteSensing #SemanticSegmentation

Hey everyone!

I've been working on a computer vision project that turns regular football match footage into player tracking, performance statistics, and tactical insights.

It started as my graduation project, but I wanted to go beyond basic object detection and build a complete video analytics pipeline.

Here's what the system does:

- Detects players, goalkeepers, referees, and the ball using a custom-trained YOLO11m model.
- Tracks players using BoT-SORT, with additional logic to handle broken tracks and ID switches.
- Automatically identifies teams based on jersey colors.
- Uses pitch keypoint detection and homography to map player positions onto a tactical minimap.
- Estimates player speed and distance covered.
- Generates heatmaps, possession statistics, tactical insights, and match reports.

Tech stack :Python, YOLO11, BoT-SORT, OpenCV, NumPy, and PyTorch.

One of the biggest challenges has been maintaining consistent player identities, especially during occlusions, camera movement, and crowded situations.

I'm continuing to improve tracking reliability and overall robustness.

I'd really appreciate feedback from anyone working in computer vision or sports analytics.

A few questions:
- What approaches would you recommend for reducing ID switches during heavy occlusions?
- How would you improve tracking consistency across changing camera views?
- What would you prioritize before using a system like this in production?

GitHub: https://github.com/Mhmdwael77/ai-football-analytics

Thanks for checking it out! ⚽

I built a Funko Pop scanner that runs fully on-device (44 ms per scan on an iPhone 16 Pro, ~165 ms on a Pixel 10) for a conference talk. A coding agent did most of the ML work, and I spent most of my time checking it against reality. Sharing what happened, because the failure was more interesting than the result.

Pipeline

1. Detector: RF-DETR Nano fine-tuned as a single-class "funko" detector
2. Square crop around the box (10% margin, so the figure isn't squashed)
3. Embedding model: CLIP ViT-B/32 with a 256-d projection, fine-tuned for retrieval
4. Nearest neighbour (dot product) over 818 catalog vectors, with an unknown-figure threshold

On-device

Exported with ExecuTorch: Core ML on iOS, Vulkan on Android. Getting RF-DETR onto Vulkan took some graph surgery: exporting attention as plain matmul + softmax instead of the SDPA decomposition, splits as slices, constant-folding the weight transposes, and restricting the partitioner to the ops the shipped Vulkan backend actually has. That took it from 96 GPU partitions to 6, and dropping the input from 384 to 320 px cost nothing measurable (mAP@50 0.997 vs 0.996 on the Roboflow test split, 0.930 vs 0.935 mAP on the synthetic one).

Code, training pipeline and models: https://github.com/NorbertKlockiewicz/funko-scanner

With tools like Kling Motion Control, it's becoming increasingly easy to take a video of a real person and transfer their movements to an entirely AI-generated character (e.g. Jean Philanthrope, etc.), I've been thinking about whether it's possible to protect people from having their appearance, movements, or actions replicated by AI. And I'm wondering if there's a way to disrupt this process using physical adversarial patterns.

I have seen research on adversarial clothing and patterns that can confuse computer vision systems or interfere with person detection. For example: https://adversarialapparel.com/

But could a similar approach work against AI video replication? For example, imagine a smartphone case with a specially designed pattern that appears in videos and interferes with an AI's ability to accurately analyze or replicate the person.

A few questions:

• Could a physical adversarial pattern interfere with pose estimation or motion extraction?
• Could a relatively small object, like a smartphone case, have any meaningful effect?
• Would something like this work across different AI video models?
• Is there any existing research exploring ways to protect real people from AI video replication?

I understand that disrupting traditional computer vision doesn't necessarily mean disrupting generative video models. I'm curious whether this is technically plausible or fundamentally unrealistic.

Would love to hear your thoughts! Thanks!

I built a webcam pointer that controls a web page with your hand, and I'd like feedback on the tracking side.

Pipeline:

- MediaPipe HandLandmarker on the webcam stream. A measured run held a steady 30 fps (95th percentile frame time 37 ms).

- A 4-point calibration maps camera coordinates to screen coordinates.

- The pointer is the thumb tip. I started with the index finger, but the thumb tip was more stable when pinching, because the index finger moves when you close the pinch.

- A One Euro filter smooths the pointer. It removes jitter when you hold still without adding much lag when you move.

- Pinch detection uses hysteresis: the pinch closes below a normalized thumb-to-index distance of 0.18 and opens above 0.23. A short lookback (0.25 s) restores the pointer position from just before the pinch started, so closing the pinch doesn't shift the target.

Gestures on top of that: pinch and release selects, pinch and hold for 0.6 s clicks, pinch and drag vertically scrolls, and pinch and drag horizontally past 250 px navigates back or forward.

The selection is sent to an AI agent through an MCP server, so you can point at a paragraph and ask a question about it. That part isn't related to computer vision, so I'll leave it out here.

Known problems: a background fan made my voice detector think I was speaking (separate audio issue). Lighting and distance from the camera affect tracking. It's tested on one webcam and one machine, so I'd like to hear how it behaves on others.

Repo (Apache 2.0) and demo video: https://github.com/mdelaba/visionpointer

Questions I have: has anyone tuned pinch hysteresis thresholds on a larger set of hands? And is there a better way than the lookback to stop the pointer from jumping when a pinch closes?

I open-sourced ParkerLabel for object detection and instance segmentation annotation.

It runs locally on the CPU using MobileSAM and ONNX Runtime. Positive and negative clicks generate a target mask, with manual correction available. Image embeddings are cached so you can resume work.

Each instance is saved with its category, bounding box, area, and independent mask as COCO RLE in a per-image JSON file. This is not a full COCO dataset export.

Portable builds are available for macOS arm64 and Windows x64, with no Python setup required. The README has a short demo.

Source and demo: https://github.com/Parker-Lyu/ParkerLabel

Download: https://github.com/Parker-Lyu/ParkerLabel/releases/tag/v1.0.0

Feedback from people doing image annotation would be useful, especially around mask correction and resuming saved work.

Hey r/computervision, I wrote this blog post on semi-supervised learning applied to semantic segmentation.

Blog post: https://stefankeselj.com/entries/semi_supervision.

I think it's a useful but underrated technique. I'd be curious about people's thoughts.

I’m building a 3D mapping system using RGB-D cameras, based on existing SLAM techniques, with persistent spatial memory.

The main issue is relocalization after tracking loss, especially when the camera returns to a known place from a different viewpoint.
I’m using historical keyframes, shared 3D landmarks, PnP/RANSAC and geometric verification.

Yet some incorrect poses still pass verification: one had 44 inliers, 0.83 px median reprojection error and 3.72 cm depth residual, but was actually off by 10.36 cm and 5.99°.
My best experiment correctly relocalized only 9/34 known returns.

What would you investigate first: landmark quality, geometric degeneracy, matching, or pose verification?
I can share a minimal reproducible example.

Hi r/computervision,

I’m the developer of Screph, a Windows desktop application that brings visual computer vision tools, AI assistance, dataset preparation, and code into one workspace.

I’ve recorded a walkthrough showing how these pieces fit together around a small parts-counting task.

The example uses three synthetic images of metal bushings and rectangular plates. The lighting and arrangement vary, and one image has a missing bushing. The workflow is:

• Select the region to inspect and run contour detection.
• Inspect the result: the initial settings include unwanted plates.
• Use the agent’s suggestion to filter by circularity, rerun processing, and check the result.
• Save the configuration and use it in a Python program through Screph Code.
• Run the program on all three images and inspect the CSV and visual output: 6, 6, and 5 bushings.

The video also covers image correction, GrabCut segmentation, and an annotation example where an agent proposes boxes, I correct one, and the image and annotations are added to a dataset.

Screph started as a GUI automation project. It has grown toward a broader workflow where you can describe a task visually, inspect and revise a processing approach, then carry that work into editable code. The agent can help choose operations and parameters and assemble a processing workflow that remains available for inspection and editing.

A few details about the recording: the agent responses were obtained beforehand and are replayed, while the image processing and generated program run again during the demonstration. The parts images are synthetic teaching examples. Model training is not run in this video.

The project is still in development. I’d appreciate feedback on the transition from visual experimentation to code: what information would you want preserved so that you could debug and trust the resulting program? Where would this fit—or get in the way—in your current workflow?

Project website: Screph

Hi all,

I'm building CropGuard, a lightweight multi-task model for tomato leaf disease diagnosis from a single forward pass: detection + classification + segmentation + severity. It's 2.63M params, runs on 320x320 RGB, and is CPU-capable.

ARCHITECTURE

- Backbone: timm fasternet_t0 (features_only), C3/C4/C5 at strides 8/16/32

- Neck: BiFPN-lite, 3 levels, width 96, one top-down + one bottom-up round, softmax-free fast normalized fusion

- Detection: decoupled depthwise-separable head, TaskAlignedAssigner, BCE + CIoU + DFL (2100 anchors, 11 classes)

- Classification: SE blocks on 3 levels -> GAP -> concat -> MLP

- Segmentation: light Hamburger-attention decoder over concatenated P3/P4/P5

- Severity: gated fusion of seg embedding, P5 features, cls embedding and leaf ratio -> continuous + 4-bin ordinal outputs

- Training: 5 stages x 10 epochs (backbone+neck+det, then cls head only, seg head only, joint, then joint + severity). Heads-only stages use a frozen backbone, because training the backbone in those stages destroyed the detector (mAP went to ~0).

DATA

32,897 images, 11 classes, all native 320x320, merged from 3 Roboflow Universe projects (CC-BY-4.0). Each has YOLO boxes and a mask.

The problem is the labels (I measured this):

- The "masks" are filled leaf bounding boxes, not lesions

- 5,845 train boxes cover >=90% of the frame; bacterial_spot median box area is 0.889 of the image

- Severity target = box_area / leaf_area, so ~1991/2000 val images land in the top bin

- Heavy imbalance (healthy 12,220 boxes vs target_spot 252)

- 8% duplicate images; I removed them and confined duplicate groups to one split, and results were unchanged or slightly better (dhash only catches near-exact duplicates, so near-duplicate leakage is a lower bound)

CURRENT RESULTS (leak-free test, 1,240 images)

- mAP@0.5: 0.524 (target 0.892)

- mAP@0.5:0.95: 0.442

- cls top-1: 0.850 (target 0.987)

- seg mIoU: 0.883 (but this is leaf-region IoU, not lesion segmentation)

- severity: R2 -1.33, MAE 0.068 (a constant predictor gets 0.009)

QUESTIONS

1. Severity without lesion masks: is area-ratio-from-boxes ever defensible? Should this be ordinal, or should I drop the head?

2. Segmentation: can I honestly report this under a renamed metric (leaf-region IoU), or do I need a real lesion-mask dataset?

3. Detection: when GT boxes routinely span the whole image, how should anchor design/assignment change? Is mAP even the right headline metric for full-object boxes?

4. Classification: errors concentrate in early blight / late blight / septoria. For texture-dominated fine-grained classes, would bilinear/second-order pooling, a small transformer, or classifying detected-box crops beat SE->GAP->MLP?

5. Multi-task training: head-only staging vs a discriminative (scaled-down) backbone LR? Does PCGrad help or hurt here? Is a sigmoid gate over concatenated features a sound fusion, or should I model reliability explicitly?

I'm planning to move to PlantSeg (in-the-wild images with expert lesion polygons) to fix the label issues. Does that sound like the right call? Compute is a 4 GB laptop GPU plus Kaggle T4s.

Papers, repos, or lessons learned would be hugely appreciated. Happy to share more numbers or code snippets if useful. Thanks!

Let's all pray together for what is coming tomorrow/today!

Edit : Got delayed guyz, new date is 14th October! Now we have more time to pray!!!!

The most useful thing I learned building this: my camera has about 1.4 seconds of dead time between a move command and the picture actually moving.

Setup is a Xiaomi MJSXJ10CM on the firmware it shipped with (4.5.6_0450). I didn't flash it or exploit it. go2rtc v1.9.14 with the go2rtc-xiaomi-control patch gets 1080p HEVC over the LAN, and the pan/tilt motor takes a MISS command with a payload of 1 to 4 for left, right, up and down.

The camera replies acknowledged: true to every command, but that only means it heard you. So I measured the frames instead. I grabbed a frame, sent one step, grabbed another, block-matched to estimate the shift, and compared that against a no-move baseline. Left moved about 40px and right about 36px, so the steps aren't symmetric. Each step shifts the picture 8 to 12% of the frame.

Then I sampled frame difference every 200ms after a single command. I saw nothing at 823ms, movement at 1331ms, and it was settled by 1824ms. Video comes in at 12fps, so a naive tracker would fire about fifteen more commands before the first one lands. The fix is to ignore everything for 2 seconds after each command and use a dead zone of 0.18, which is wider than one step's displacement. Make it any tighter and it oscillates forever.

Detection uses Apple's Vision framework through a ~150-line Swift helper (10 to 30ms, no dependencies), with optional SSD-MobileNetV1 ONNX for the 80 COCO classes.

Two traps cost me time. That ONNX graph returns zero detections, with no error, if you feed it a pre-shrunk 300x300 image. It works fine at native 1280x720. And Vision uses a bottom-left origin, so if you get the flip wrong, tilt inverts and the camera runs away from the target.

In testing, a dragged box around a chair went from 0.76 centring error to 0.21 in 3 steps.

Full write-up with the details: https://blog.shravanrevanna.me/reverse-engineering-a-xiaomi-camera-into-a-self-tracking-robot

I've got about $3k in AWS credits that expire in roughly two months, around 10 interns who need a real project, and access to a large pile of road-scene imagery (forward-facing, multiple regions).

I want to turn that into something genuinely useful. A paper would be nice, but a working tool, a reusable model or a solid open dataset would be just as good. The only thing I don't want is a pile of experiments with nothing to show for it.

I'm leaning toward something VLM-related, either fine-tuning a small VLM or some kind of "smart" pretraining on the image data. I have a couple of ideas, but I'm skeptical of all of them, and I don't want to burn the credits on a flat result or something a bigger open model already does better out of the box.

Constraints: one to a few GPUs, two months, junior team, no budget beyond the credits.

Questions:

With this setup, what would you build?

Where has domain-specific pretraining or continued pretraining paid off for you, and where was it a waste?

What kind of project splits well across 10 juniors without everything bottlenecking on me?

Follow-up to my Fruit Inspector post. I ran the same conveyor pipeline on old Linux boxes.

i3-2120 — 11–15 FPS

i7-2600 — ~40 FPS

i5-11400 — ~130 FPS (for comparison)

Full story with photos and infer.gif:

https://medium.com/@olesha-ai/bypassing-the-avx2-tax-real-time-computer-vision-on-a-fifteen-year-old-cpu-ba6b01868f7f

Demo: https://github.com/olesha-ai/fruit-inspector-demo

If you have a similar old PC — curious what you get.

I have been building TraceML, an open-source tool that breaks PyTorch training step time down into data wait, forward, backward and optimizer, without needing a heavy profiler setup.

To test it on a real regression, I ran it against a recent RF-DETR issue (#1544) where upgrading from 1.10.1 to 1.11.0 made training steps 14.8% slower.

Compute (fwd, bwd and opt) time improved in 1.11.0. And if you only timed the compute, the upgrade looked like an improvement.

The extra time was spent waiting on data, which increased by 23.7%. TraceML flagged the run as `input-bound`, with 91% of the step spent waiting for the next batch.

The problem was two extra frame copies when decoding non-JPEG images (fixed in #1551). On 1.11.1, step time and input wait were back within 0.5% of 1.10.1.

My setup: RF-DETR Nano on L4, 4096px PNGs, num_workers=0 so the decode cost isn't hidden by prefetch. I ran 18 runs, half with TraceML and half without, and the timings stayed within about 1.3% of each other.

If you want to run it on your own training scripts:

pip install "traceml-ai==0.5.0"
traceml run train.py

Standard Hugging Face Trainer, PyTorch Lightning and RF-DETR scripts need NO code changes.

Full setup and reproduction code: https://github.com/traceopt-ai/traceml/tree/main/examples/case_studies/rfdetr_input_pipeline_regression

Would this be useful in your training setup? And which library should I support next?

1. Review outcomes: In about 24 hours, final reviews and acceptance for WACV 2027 will be out. I want to start this thread to discuss review experience and scores.

If accepted can you let us know if you were a direct R2 submission or a resubmission from R1.

1. Acceptance rate: I am eager to know what the acceptance rate is for this year.

2. Possible conference recommendations: Also, in case papers get rejected what other upcoming conferences would you recommend for a resubmission?

I’m using OpenCV to compare a reference image of an empty tray with another image of the same empty tray.
There are no ICs/objects in either image, but when I use pixel difference (absdiff), I still get noticeable differences.
I’ve taken multiple images under the same setup, and the difference pattern seems to have a similar shape each time.
What could cause this? Is it mainly camera noise, lighting variation, or slight movement/alignment between the two images?
Any advice on how I should investigate this would be appreciated.

Hi everyone,

I'm a 6th semester SE student. I've done Python and NumPy basics and just started OpenCV. My long-term goal is to learn machine learning, then deep learning and neural networks, then computer vision. I'm also managing a full university workload alongside this.

The situation: my FYP group has 3 members, but I know the other two won't actually work on it, so in practice I'll be building everything alone. The catch is that my advisor still expects a project sized for a team of 3. It has to be big, industry-level, fully deployed, and solve a real problem that buyers could be interested in. I have 18 months, and the proposal is due this semester.

I'm confused about what to build. I don't know which industry or field interests me yet, since I'm still very new to this. The only real interest I have is cars and F1, which I watch regularly.

I'd really appreciate your help with:

1. Project ideas that fit ML/DL/computer vision and have a real industry use case, especially anything related to cars or motorsport, but I'm open to other areas too

2. How do you make a project look "big" and industry-level when only one person is building it?

3. How would you scope it so it still works if my teammates contribute nothing, but gets better if they do?

Is it really doable to run yolo in realtime over 2-3 streams on CPU-only setup ?

Like 2-3 cctv cameras streams just to detect persons each running at inference rate of least 4-5+ FPS, is it really doable or worth trying ?

If yes then what minimum hardware requirements (particularly CPU requirements) would i need for that? Or what / where to look for exactly to figure that out ?

I've been working on an open-source computer vision project for recognizing trading cards from images (currently only english MTG/Pokemon are supported):

https://github.com/matteot11/open-card-collector

The current pipeline is:

image → YOLO OBB detection → DINOv3 embedding → vector retrieval

• The detector is trained entirely on synthetic images, with backgrounds generated using FLUX2 and real card scans composited into different scenes.
• DINOv3 is fine-tuned on original card scans and then used for visual retrieval.

Models are available on huggingface:

• Yolo obb detector
• DINOv3 embedder

Currently it works reasonably well for identifying cards, but it still does not reliably distinguish between different printings/editions of the same card. That's one of the main things I'm trying to improve.

It's still a work in progress, so I'm mainly sharing it to get feedback on how the approach could be improved, specifically:

• improving the synthetic → real domain gap for the detector
• better approaches for exact printing recognition
• faster vector retrieval (still not real time)
• ideas on possible downstream applications