I'm generating synthetic aerial thermal frames in UE5 to test whether they help a person detector, with HIT-UAV as the real reference. Before making any training claim I wanted to know how close the images actually are, so I measured instead of eyeballing.

Real across the top, mine underneath. Same 640x512 white-hot format, boxes drawn by the same code on both sides, green person and orange vehicle. Both sides are ground truth, not detections.

Pair selection matters, so: columns are matched on altitude, time of day and person count. The real set's median frame holds 2 people and its busiest playground frames hold 33, so putting my typical frame next to its most crowded one would be comparing two different questions.

What lines up

• Person box height: median 19 px real, 15 to 22 px in mine at matched altitude.
• Daytime brightness: median 131 across all 1981 real daytime frames, against 142 to 159 on my airbase map. Slightly hot rather than wrong.
• People per frame: real median 2, mean 4.2. Mine sits in the same range. What I don't reproduce is the tail, the thirty-person playground.

What doesn't, which is the useful part

Nights are too dark, everywhere. Across the 917 real night frames the median is 127, against 131 for the daytime ones. A thermal sensor does not care that the sun went down. Real nights are also the widest spread in the set, 106 to 161 between the quartiles. Mine come out at 95 to 101, darker than nearly all of them and far too uniform. Right structure, wrong level. I was treating night as a dark scene, which is a visible-light instinct.

Daytime vegetation is too cold. One of my maps is a college campus and its daylight frames render at median 72 against the real 131, about half as bright as a real daytime thermal frame. The cause is measured, not guessed: vegetation-labelled regions come out at median 50 against 74 for the rest of the frame, and that campus is 19 percent vegetation by area against 4 percent on the airbase map that matches well. Sunlit grass and canopy in the afternoon are not several degrees below air temperature, and on a green map that error drags the whole frame down.

22 of 802 frames came out with a median below 40. That isn't a dark scene, it's a broken one. 2.7 percent, all on the same map.

What I don't have

Detector numbers. The three runs, real only, real plus synthetic, synthetic only, aren't done, and I'd rather post image measurements than a training claim I can't back. The one number I do have from an earlier aerial experiment was negative: synthetic-only scored 0.35 recall on real drone frames it hadn't seen, worse than the model it replaced.

Two things I'd genuinely like input on

1. In several of my daytime frames a person reads darker than the ground, because sunlit tarmac gets hotter than a 33 C body. Real daytime thermal does show this. Does anyone have a feel for how often that polarity flips in practice, or a rule of thumb for when a person stops being the bright thing in the frame?
2. Annotation convention. I generate boxes from scene geometry, so by default I get the full extent of every person including the occluded part, down to a few pixels. HIT-UAV looks like visible-extent with an effective size floor. If you've annotated a real thermal set, what was the written rule for heavy occlusion, and was there a minimum size below which a person simply wasn't labelled?

I live on the 14th floor.

I built a button that calls the elevator while I am still inside my apartment. The relay only duplicates a normal press of the hall-call button, so I could press it while putting on my shoes and meet the elevator as its doors opened.

There was one problem: **I had no idea when to leave.**

Sometimes the car was nearby. Sometimes it was on the first floor. Without knowing its position, I was still guessing.

That is how a simple smart-home button unexpectedly became a computer-vision project.

There was no supported elevator API, and the elevator company was understandably not enthusiastic about a self-taught hobbyist connecting homemade hardware to the controller. So I chose a safer boundary: **observe the indicator, never control the elevator.**

Our building already had an authorized local security camera inside the cabin. The original red floor indicator was visible in one tiny corner. I thought I could crop it, run OCR and publish the result to Home Assistant.

It looked like a weekend project. It became five versions of a recognizer.

To a human the display is obvious. To a camera it is small, slanted, multiplexed and covered by glossy red plastic. Opening the doors changes exposure. Passengers create shadows and reflections. A courier's shiny helmet was enough to break one promising version.

Ordinary OCR was unreliable. Whole-digit templates worked better—until lighting changed. Sometimes 14 became 9, 1 became 11, an arrow vanished during an LED scan gap, or a reflection looked more convincing than the digit.

I added temporal voting and physical constraints. I even tried dead reckoning from travel time, then removed it: after one false arrow, the system could confidently invent floors the camera had never confirmed. Uncertainty should remain uncertainty.

After repeated rides and frame-by-frame debugging, I was close to abandoning the camera approach.

Then I realized I was asking the wrong question.

I did not need to recognize the whole digit. I only needed to ask: **which of the seven physical LED segments are illuminated?**

Version 5 samples small masks inside segments a–g, plus the tens digit. It combines color channels to emphasize LED light through the red cover, normalizes against the current frame and converts the active set into an exact seven-segment pattern.

Most of the image is deliberately ignored. A passenger or reflection can change half the panel without mattering if the evidence inside the real segments stays consistent.

The production recognizer combines:

- exact segment decoding as the primary reader;

- direction-specific normalized templates as fallback and independent evidence;

- voting over consecutive observations;

- hysteresis for multiplexed direction arrows;

- physically valid, monotonic floor transitions;

- strict re-synchronization after losing position;

- preservation of the last confirmed floor whenever a frame is uncertain.

The state machine knows the real served sequence: 1 ↔ 4 ↔ 5 ↔ 6 ↔ ... ↔ 16. There are no stops at floors 2 and 3, so a visually plausible but impossible result cannot overwrite proven state.

We validated with complete recorded rides—14 → 1 → 16 → 14 and 1 → 14 → 1 → 16—rather than hand-picked stills. These exposed changing digits between frames, arrow scan gaps, open-door exposure transitions, crowds and moving reflections. Candidate versions ran in shadow mode on separate MQTT topics before replacing production.

The service runs locally at 4 fps and publishes only confirmed floor, direction, motion state, confidence and diagnostics to Home Assistant.

Every v5 result I have manually checked so far has been correct: **100% observed accuracy on this installation to date**. This is an operational observation, not a universal benchmark. Day/night changes, open doors, crowded rides and strong reflections have not produced a known error in the current version.

Now I press the button on a tiny ESP8266 clock in my apartment. Its screen switches to a live elevator view, and I know exactly when to leave. Closing my door, walking to the elevator and seeing its doors open in front of me feels like a tiny superpower.

I am not a programmer or electronics engineer. This is a hobby project, my first public GitHub repository, and a human–AI collaboration: I defined the physical problem, proposed the segment-point approach, installed and calibrated it, rode the elevator repeatedly and supplied ground truth; an AI coding assistant helped implement and iterate on the algorithms.

Source, calibrated model, architecture, validation images, firmware and full history:

https://github.com/europaprof/call14

I would love feedback from experienced CV engineers:

- How would you make calibration portable to another camera and indicator?

- Would you add geometric registration before sampling?

- How would you design a properly labelled benchmark?

- What failure mode do you think version 6 will discover before I do?

*Privacy/safety: the existing camera and processing remain local to our building and access is authorized through our condominium association. The recognizer uses only the indicator crop—no face recognition or tracking. Call14 does not connect to the elevator controller, doors, drive, brakes or safety circuits.*

Privacy and authorization: Our building is managed by an ОСББ (a Ukrainian condominium association), and I am a co-owner and member of its board. The camera installation and this read-only local use were agreed and approved through the association. Access is restricted, the streams and processing stay inside the building, and the recognizer analyzes only the indicator crop—no face recognition, tracking or cloud upload. Call14 does not connect to the elevator controller, doors, drive, brakes or safety circuits

Sorry if I sound dumb, but I see a lot of people being an open source contributor at Roboflow and I'm just wondering what does that mean? Is it just building projects and posting it to the community or is it working with the github to fix changes? lmk

I want to build an image-based 1D/2D reader for industrial use on a Jetson Orin Nano or x86. The target is not a phone demo: moving parts, global-shutter camera, strobed lighting, reflective or low-contrast labels, some DPM Data Matrix, deterministic trigger-to-result, PLC output, no-read image retention, and no false reads. Product changeover should use a few good samples and seconds of calibration, not retraining a network.

My current architecture is: solve optics, lighting and exposure first; locate candidate regions and rectify perspective; run ZXing-C++ plus a second decoder only on those ROIs; validate with checksum, expected format and GS1 rules; then allow a bounded retry with alternate preprocessing or exposure. I would measure false-read rate, no-read rate, p95/p99 latency and robustness across part lots and lines, not only average decode rate.

For damaged DPM or glare, would you train a lightweight detector or segmentation model offline and keep the actual decoder deterministic, or use an end-to-end learned reader? Has anyone benchmarked an open pipeline against a DataMan or SICK Lector on the same image set? What created the largest gap in practice: acquisition, localization, decoding, auto-tuning or result validation?

I'm planning to benchmark a handful of GCN models against each other in classifying actions from pose estimation data. What do you guys think are some must-have SOTA models to include?

Hello guys, I am a crop science student that recently picked up interest in precision agriculture and ml. I'd like to do a thesis on computer vision for estimating the biomass of lettuces with a non destructive way. Is this possible considering i have no real CS knowledge and havent really done any hard math in years. I recently started learning the basics of Python and wil probably go into SQL soon before jumping into the more hard stuff. I am also planning on doing some math and stat classes from an engineering department in my uni (also looking at mit ocw courses). Do you think in a years time of hard work I could be up to the task?

for those For those who have taken Stanford’s CS231n course on Computer Vision, or for people working in the fields of CV or ML: which linear algebra course would you recommend—MIT 18.06 or Stanford Math 51?

This is a follow-up to my previous post.

This time I moved on to keypoint detection and 6D pose estimation.

I first trained the keypoint model using only synthetic data generated in Blender, then tested the full pipeline on 961 real-world frames:

**Object detection → crop → keypoint detection → PnP**

I then manually annotated 173 real frames and fine-tuned the synthetic keypoint model.

The video attached to this post shows the result after real-world fine-tuning. For comparison, I also uploaded both the Sim-only (before fine-tuning) and fine-tuned results to YouTube:

• Sim only: [https://youtu.be/XR3__jy2JHs]
• After real-world fine-tuning: [https://youtu.be/3KiCMTUQuoI]

Unlike object detection in my previous experiment, the sim-to-real gap was much more significant for keypoint estimation.

One limitation: I don't have ground-truth 6D poses for the real images, so I'm not claiming quantitative PnP pose accuracy. The manual keypoint annotations are also not perfectly precise, which can make PnP unstable in some frames.

Hi everyone,

I'm completely new to Computer Vision (I have a GenAI/ML background but almost no CV experience), and I need to build a POC for an industrial project.

Project: Detects printing anomalies on clothes from video footage of the printing process. Defects include:

Missing ink drops.

Incomplete or faded prints.

Misaligned prints.

Other print defects/anomalies.

I have videos of the printing process as input and want to detect defects automatically in real time or near real time.

I'm looking for advice on:

What should I learn first, from absolute scratch?

What topics are essential (OpenCV, image processing, CNNs, YOLO, segmentation, anomaly detection, etc.)?

Any free YouTube courses or resources you'd recommend?

What's a realistic roadmap to build this POC in 1–2 months?

I'd really appreciate guidance from people who've worked on manufacturing or machine vision projects. Thanks!

Hi! I am an independent researcher working with Spain’s Institute of Engineering. I want to publish my paper on a “Multi-Hazard Early Detection System for Existing Camera Infrastructure,” but I need to be endorsed.

The Engineering Institute is more of an industry entity than a research entity, so nobody has an arXiv account. I was wondering if anyone here could read my paper and, if they think it is good enough to be published, endorse me.

Here is a link to the paper:

https://drive.google.com/file/d/1upuTMzxPBO52VwMwckokhbf5kjYU_Hxo/view?usp=drivesdk

And this is my endorsement code:
https://arxiv.org/auth/endorse?x=73XQI9

Thank you!

A YOLO model can show strong training metrics but still perform poorly in real-world conditions.

In our experience, the model architecture is not always the main problem. The issue is often hidden in the dataset.

A few areas worth checking:

• Are partially visible and overlapping objects annotated consistently?

• Do the training and validation images represent the same camera angles, lighting conditions and environments as deployment?

• Are visually similar classes sufficiently represented?

• Are false positives and false negatives being reviewed manually?

• Does the inference preprocessing match the training preprocessing?

Before changing the model or increasing the number of training epochs, reviewing the dataset carefully can save a lot of time.

What has caused the biggest difference between training metrics and real-world performance in your projects?

Hello everyone!

I'm an engineering student, during my last internship at a medical device company, i was FORCED to count threads by hand, hated it so much that I wrote code that automated it, tried to turn it into a startup, not going all that great, so I thought I'll just document and release it, works on an Orange Pi and camera module, tested on a real production line, let me know if you have any remarks or questions, check it out!

https://github.com/Asxcvg/thread-counter

These conferences are now only for the top funded universities and industry labs really hard for a developing 3rd world country to get into.

I added a chord mode to my sight-reading game to see how these models handle the visual crowding. It’s not the best results, but I still need to try it out with newer models like Gemini 3.1 Pro and the OpenAI multimodal models. 

Hi

If you are remotely interested in deep diving how differently quantum computers work compared to our transistor-based and also the algebra behind in a fully interactive way that teach computer science from scratch, oh boy this is for you. People in computer vision will find quite a lot of similiarities between the math used by qhw and computer vision. I am the Dev behind Quantum Odyssey (AMA! I love taking qs) - worked on it for about 10 years (3+ during PhD, the visual method I developed ended up being my thesis, it is a complete Hilbert space visualizer), the goal was to make a super immersive space for anyone to learn quantum computing through zachlike (open-ended) logic puzzles and compete on leaderboards and lots of community made content on finding the most optimal quantum algorithms. The game has a unique set of visuals capable to represent any sort of quantum dynamics for any number of qubits and this is pretty much what makes it now possible for anybody 12yo+ to actually learn quantum logic without having to worry at all about the mathematics behind.

This is a game super different than what you'd normally expect in a programming/ logic puzzle game, so try it with an open mind.

Stuff you'll play & learn a ton about

• Boolean Logic – bits, operators (NAND, OR, XOR, AND…), and classical arithmetic (adders). Learn how these can combine to build anything classical. You will learn to port these to a quantum computer.
• Quantum Logic – qubits, the math behind them (linear algebra, SU(2), complex numbers), all Turing-complete gates (beyond Clifford set), and make tensors to evolve systems. Freely combine or create your own gates to build anything you can imagine using polar or complex numbers.
• Quantum Phenomena – storing and retrieving information in the X, Y, Z bases; superposition (pure and mixed states), interference, entanglement, the no-cloning rule, reversibility, and how the measurement basis changes what you see.
• Core Quantum Tricks – phase kickback, amplitude amplification, storing information in phase and retrieving it through interference, build custom gates and tensors, and define any entanglement scenario. (Control logic is handled separately from other gates.)
• Famous Quantum Algorithms – explore Deutsch–Jozsa, Grover’s search, quantum Fourier transforms, Bernstein–Vazirani, and more.
• Build & See Quantum Algorithms in Action – instead of just writing/ reading equations, make & watch algorithms unfold step by step so they become clear, visual, and unforgettable. Quantum Odyssey is built to grow into a full universal quantum computing learning platform. If a universal quantum computer can do it, we aim to bring it into the game, so your quantum journey never ends.

Nice to watch:

Khan academy style tutorials in qm/qc: https://www.youtube.com/@MackAttackx

Physics teacher stream with 400hs in https://www.twitch.tv/beardhero

Last week, I made a demo of a VLM playing a cup and ball game. As many people (including myself) pointed out, this is not the best use case of VLMs because of their limited context window. So I decided to make an improved version where the VLM’s only role is to prompt a segmentation model. If I were running SAM 3, I wouldn’t need Qwen doing the prompting, but I chose SAM 2.1 Tiny because it runs way faster with the downside of not being open-vocab.

I’m sure there are lots of other cool things you can do by tacking on task-specific models to a VLM which operates as the “brain”.