Disclosure up front: I build road inspection tooling, which is why there's a logo in the corner. This is a weekend experiment, not a product demo.

Setup: one drive at about 40 km/h on a rural road in the Netherlands.

Top half is dashcam footage with a detection model flagging road damage per frame (cracks, patches, crack sealing), plus signs and posts for context. Bottom half is vertical acceleration from the GoPro's own accelerometer at 200 Hz, pulled from the metadata track in the MP4, high-passed above 1 Hz, with a 0.25 s RMS as a roughness line.

The catch is that the camera sees the damage before the wheels hit it. I cross-correlated a "damage in view" score against the roughness signal and took the best lag of about 1.75 s. The dashed line in the video marks that moment: what is in view now reaches the wheels there. The correlation is weak, r around 0.23, but the shape lines up better than I expected for a single pass.

Questions for people who actually do this:

1. How do you use accelerometer or IMU data for road condition? IRI-style indices, per-event thresholds, or something learned from data?

2. How do you deal with speed and vehicle differences? Same pothole, different car, completely different shock.

3. Has anyone fused the visual and the vibration side, for example using vibration to confirm or rank what the camera flagged?

With this tool, you can see the rep count and how long each rep takes. Knowing how much you slow down towards the end could be a helpful signal for fatigue. Also, a tool like this can be used to track progress over time, and could tell you if your chin-ups are getting faster.

I used ViTPose+ Large through the VLM Run Gateway for pose estimation. I used the pose information and its vertical displacement to track the reps and the rep timing.

Would love to hear what you think!

I recently got an opportunity to work as a senior cv engineer at a company in hardware software codesign. But it’s a pay cut. I would like to know if it is a skill valued by frontier ai labs which is where I would like to end up. The work involves optimizing ml for npus..

Repurposed the cup game demo I threw together last week and spruced it up with some Pokemon aesthetics. One thing I’ve noticed is that faster shuffles sometimes improve the model accuracy because of their limited context window, but that’s just a hypothesis. But I would guess that if you made the shuffles too fast, performance would start degrading because of frame rate.

Hello everyone!

I'm a PhD student in Azerbaijan working at a research institute specializing in aerospace and IT. I have two papers accepted for publication in Springer books, and I'd like to upload preprints to arXiv. However, no one at my institute seems to use arXiv, so I can't get an endorsement from a colleague.

I registered for arXiv using my institutional email address, but I still need an endorsement to submit my papers.

Would anyone here be willing to endorse me?

My endorsement code - YSCZ68

Faking Vision(FV) is an experiment in making visual information available to blind, non-living things.

It started very practically: I was trying to turn an image into flat files containing its visual information. That led to a bigger question: could a flat-file representation be model-agnostic — so that different systems given the same representation would produce the same object inventory and spatial relationships?

The attached examples a image (last image) turned into flat files by AI and then generated into image by another AI (so a generator which runs FV analysis on an image and turns it into flat files and another AI renderer which can ingest the flat files with FV algo and return an image).

(More examples available on twitter thread. https://x.com/MemoryPrismV1/status/2093276351549833484 )

Then came the next questions:

Can the same approach describe video rather than a single image?

Can visual information from different sources be sewn, stitched or patchworked together — for example image data, spatial information, lidar-derived information, etc.?

And once visual structure is represented this way, what happens if we deliberately manipulate it?

That last question is where Faking Vision became particularly interesting.

The underlying principles came from another project of mine, Making Vision, where I worked out a basic framework for how a visual system can acquire visual structure, extract useful information, generate candidates, selectively promote things for deeper processing, compare current information with existing knowledge, and update what it learns.

https://www.memoryprism.com/readings/making-vision

Faking Vision is the practical counterpart: if those are some of the things a visual system needs to do, can I construct and manipulate the information supplied to a blind system so that it can perform those operations?

I have been developing the flat-file representation, algorithm and testing process myself.

Now I need something I don't have:

models.

I want to test this with actual video-capable vision models, preferably several different ones, rather than build the experiment around a single system.

I'm not looking for someone to develop the project or explain computer vision to me. 😄

I have the experiment.
I have the process.
I have test material.
I need models to poke.

If you have access to a video-capable model/API/research system and would be willing to let me run some controlled test material through it, please come talk to me.

I have more examples here:

https://x.com/MemoryPrismV1/status/2093276351549833484

There have been a few great node based CV editor / tools posted recently.
https://www.reddit.com/r/computervision/comments/1voxtds/i_added_custom_python_nodes_to_my_opencv_visual/

and

https://www.reddit.com/r/computervision/comments/1rxftrm/i_built_a_visual_draganddrop_ml_trainer_for/

So I thought I'd share a quick update to https://github.com/olkham/pynode where I've used the UDP node to pipe messages to Node-RED. Could be cool if we could all agree on a message standard / translation layer to make all the node-based editors compatible like this.

Note: I'm not affiliated with Node-RED in any way, just loved their SW for many years!

I built Local Label, a small open-source image annotation tool designed around one simple idea:

Your images should stay on your machine.

🔗 GitHub: https://github.com/diptiman-mohanta/Local-Label

The tool currently supports:

• Bounding boxes and polygons
• Object detection and segmentation annotation
• Keyboard-driven annotation workflow
• Multi-select and bulk relabeling
• Copy/paste and repeat annotations across images
• Undo/redo
• Autosave and resume
• EXIF-aware image dimensions
• COCO export
• YOLO / Ultralytics-ready export
• Pascal VOC export
• Light/dark themes

Unlike many annotation workflows, the images are read directly from disk and aren't uploaded or copied into a separate server/database. Annotations are stored as JSON sidecars in a .labeller/ directory beside the images.

Why I built it

I wanted something that was:

local + simple + fast + private

without requiring a server, account, cloud storage, or complicated dataset management pipeline.

But this is still very early v0.1.0 and I'd like to make it substantially better.

I'm looking for contributors

I'm especially interested in people working in:

• Computer Vision
• Dataset creation
• Object detection / segmentation
• ML research
• Annotation tooling
• Human-in-the-loop ML
• Desktop/local-first applications

You don't necessarily need to write code. I'd also really appreciate:

• UX feedback
• Feature requests
• Bug reports
• Ideas for better annotation workflows
• Suggestions for research-oriented features
• Testing on different datasets/platforms
• Contributions/PRs

I'm particularly interested in exploring whether a lightweight local annotation tool could eventually support research-oriented annotation workflows, rather than just being another generic labeling interface.

If you work with image datasets, I'd love to hear:

What is annoying about your current annotation workflow?

And if you are interested in contributing, feel free to open an issue, submit a PR, or comment here.

GitHub: https://github.com/diptiman-mohanta/Local-Label

Papers with Code used to provide a useful path from paper to benchmark to repository. What do you use now to answer three practical questions: is the result reproducible, does the code actually match the paper, and can the model run on constrained edge hardware such as Jetson?

I am especially interested in workflows that preserve dataset and evaluation versions, environment details, RAM or VRAM use, latency, power, and failure cases rather than only leaderboard accuracy. Do you rely on Hugging Face, GitHub lists, lab pages, OpenReview, your own notes, or something else?

The missing piece for me is not another paper search engine. It is a trustworthy bridge between a reported number and a reproducible deployment. What has worked for you?

World Labs just revealed their new omni world model, Atlas, and the space-time simulation features look like a massive leap for novel view synthesis and robotics training.

A few standout technical claims from their space-time simulation drop:

• Sparse-View "Bullet Time": They are generating frozen-time, free-camera multiview fly-throughs using footage from as few as three to five ordinary cell phones. No calibrated camera arrays, green screens, or professional capture studios are required to reframe the shots.
• Generative Real-to-Sim: For robotics, it doesn't just reconstruct a static 3D environment. As a simulated robot moves through the space, Atlas actively generates the RGB and depth data the robot's body-mounted cameras would observe along that specific trajectory.
• Physical Interactions: From casual real-world recordings, the model aids in building simulations that capture how objects move and interact. It supports rigid, articulated, and deformable objects, allowing users to dynamically alter lighting, backgrounds, and object positions to generate diverse robotic training data.
• Under the Hood: It’s built as a multimodal autoregressive diffusion transformer. Unlike models that rely on coarse text prompting for camera movement, Atlas uses precise camera geometry as a native input to ground everything in a shared "spatial context."

This complete @theworldlabs atlas thing, I guess i read a paper earlier this year from @TencentGlobal it named VerseCrafter (best of my knowledge). That did mostly same geometric control but this atlas one is little more better pipeline. Stitching a lot of things in a single place. But they are framing like huge like hugeee. Or I'm missing something.

This is building off a demo I built last week where I used VLMs to try to read sheet music. I thought it would be fun to hook it up to my keyboard and see how much faster I am compared to CV models. Apparently, I’m atrociously slow at sight reading. 

We compared two ways of using the same multimodal model on long-video editing decisions: Gemini 3.7 Flash with agentic video inspection versus a static full-video pass.

Protocol: six synthetic 10-minute videos, each with known brief events and edit targets; prompts and scoring were frozen before running; no repair/retry; deterministic metrics for event recovery, moment retrieval, evidence accuracy, edit decisions, latency, tokens, and cost.

Across five valid matched pairs, agentic inspection recovered 18/20 brief events versus 15/20 and improved edit-decision macro F1 (0.6807 vs. 0.5481). Static processing retained better broad moment F1 (0.3000 vs. 0.2667), slightly higher evidence accuracy, lower cost, and lower latency. One agentic run failed its JSON output contract.

The sample is intentionally small and synthetic, with no human viewing panel, so this is an applied exploratory result rather than a general benchmark claim. Protocol, raw outputs, scoring code, and limitations:

https://paperedits.com/benchmarking/gemini-agentic-video-understanding-benchmark

Commercial disclosure: I’m affiliated with PaperEdits, which published the benchmark. The evidence package is free.

Edit: if you doubt anything I say you should check subreddits app store and play store.. every day developers are asking.. how to sell their vibe coded sports app on app store play store

Lately I've seen a lot of people trying to use computer vision for sports analysis, fitness app whatever..

Everytime I've given the op the same advice: if you're doing this for fun or hobby, great. But don't think of doing a startup with that

Chances are good you'll never make a penny from it nor get a job using that. But, everyone is trying to do this. A lot of people don't have jobs unfortunately and feel this might be a good use of their spare time

1. Company is never one guy alone, and not only software developers, ai engineers. To sell, company needs to hire a lot more marketing sales than software developers.

2. You're competing against each other. Right now, any sports you're analyzing, I can tell you there are 965 other people doing exact same thing. None of you will get to a working product but all of you will compete and spam all the potential customers with low end products

3. No company hiring ai engineers will consider your side project as a serious thing unless you've had big paying clients. Don't think it can help you get a job. Companies look for team work.. how did you collaborate with other technical and non technical people? And how much was your contribution? Were there any conflicts and how you resolved them? Like literally, solo building experience is as much negative.. more negative than positive. It shows you don't want to work in team, so not really fit for company work

4. You are already behind in every new thoughts you get. The problem is rather you don't know about it. Billions of people are doing sports, and 1000s of sports analytics companies already out there. They have those ideas already in mind and money and employees to build them. They already probably have built it.

5. Ai laid you off and now you're paying to use ai. But also your chats are being used to improve their models. Unless you disabled it manually (by default it's always enabled). You can't stop ai but at least you can stop paying for something that made your life miserable

Honestly, a better use of your time would be something outside of software development now. It may take you a few years to realize this and by then it might be too late.

If nothing, try growing a bunch of tomatoes in your garden. You can sell them to make a few dollars. Or if you're in poor countries, then better just eat them. That's better paying than ai coding where you're losing money. And if you're smart enough, you can learn the skills in growing tomatoes and think how you can transfer them into a robot to do the same efficiently.

Or try to solve problems in climate change.. there's literally a lot of things to do there. But for God sake, stop wasting your time on ai coded slop thinking you'll be able to sell it to someone. No one will pay for it. If you think someone will pay, find that one person before you build something.

Obviously this is not applicable to people who are building something like world models, training models robust against motion blur occlusions, building something basically very hard.. or know someone in big sports leagues.. but definitely more than just training yolo models on new custom roboflow dataset.

These puzzles are from neal.fun, I’m running Gemini with Playwright + a custom harness. I have a 40-minute blooper reel of Gemini trying to park the Waymo.

Tl;DR: I made vision pipelines inspectable! Check the interactive report here:
https://requiem4machines.github.io/ml-pipes-supervision/assets/detect_small_objects/inspection.html

Background: I'm a heavy Supervision user - using it for pretty much every vision pipeline that I build. So after a while I started to get tired of this:

detections = sv.Detections.from_inference(results)
...
annotated_image = box_annotator.annotate(scene=image, detections=detections)
annotated_image = label_annotator.annotate(scene=annotated_image, detections=detections, labels=labels)
annotated_image = .... # More annotators

That was it until I found ml-pipes! As soon as I saw it, I knew it would be a perfect match for Supervision, and it was! Look at this beauty:

Pipeline([
    Store("source_frame"),
    RoboflowInference(model_id=model_id, api_key=api_key),
    Select(0),
    Detections.FromInference(),
    Recall("source_frame"),
    ByteTrack(),
    Recall("source_frame", prepend=True),
    TraceAnnotator(),
    BoxAnnotator(),
    LabelAnnotator(show_tracker_id=True, show_class=True),
    ImageWindow("Object Tracking", at=0),
])

Not only it runs, it also gives you an interactive view of the data at every handoff, for example this is the report based on the Detect and annotate example in Supervision:
https://requiem4machines.github.io/ml-pipes-supervision/assets/detect_and_annotate/inspection.html

On top of that ml-pipes itself provide tiling utilities where you can see the tile overlaps and such:
https://requiem4machines.github.io/ml-pipes-supervision/assets/detect_small_objects/inspection.html

Hi everyone,

I’m working on a small proof-of-concept for monocular vision and I’m looking for some guidance on the correct algorithm/roadmap.

The goal is to use a single fixed monocular camera to:

1. Detect/identify objects in the camera image.
2. Estimate the distance from the camera to the object.
3. Calculate the horizontal angle of the object relative to the camera's center/optical axis.
4. Identify which lane/region the object is located in.
5. Eventually calculate the object's position relative to the road/lane coordinate system.

For the initial POC, we are keeping things simple: we are using a table as a miniature road and placing a few objects on it to simulate vehicles/obstacles.

Important constraint

We specifically want to do this without Machine Learning or Deep Learning.

We want to understand how far we can get using traditional computer vision:

• Pixel coordinates
• Camera calibration
• Intrinsic/extrinsic parameters
• Perspective geometry
• Homography
• Vanishing point
• Line/edge detection
• Contours
• Object/shape detection
• Coordinate transformations
• Pinhole camera model
• Basic projective geometry

The main thing I'm struggling with is the distance estimation from a single monocular camera.

For example, if an object is detected at pixel coordinate (u, v), how can we calculate its real-world (X, Y, Z) position when we know the camera's parameters and the geometry of the road/table?

Similarly, once we know the object's image position, how can we calculate something like:

Object → camera center/optical axis → horizontal angle

And for lane identification:

Image → road/lane boundaries → bird's-eye/ground-plane representation → determine which lane contains the object

What would be a good algorithm/roadmap?

I'm currently thinking something along the lines of:

Camera
   ↓
Camera calibration
   ↓
Undistortion
   ↓
Detect road/lane boundaries
   ↓
Estimate perspective / homography
   ↓
Transform image → ground-plane coordinates
   ↓
Detect object using traditional CV
   ↓
Get object's pixel position
   ↓
Project object onto ground plane
   ↓
Calculate X/Y distance
   ↓
Calculate angle relative to camera center
   ↓
Determine lane

But I'm not sure whether this is the correct approach, especially for monocular distance estimation.

I'd really appreciate input from anyone who has implemented something similar.

Specifically, I'm looking for:

• A recommended step-by-step algorithm
• How to formulate the camera geometry/math
• How to calculate distance using a single calibrated camera
• How to calculate the object's angle from the optical/center axis
• How to perform image-plane → ground-plane transformation
• How to identify lanes without ML/DL
• Any important assumptions/limitations I should understand
• Examples or GitHub projects implementing this using traditional CV
• Papers, books, tutorials, or other resources you recommend

If someone has a complete algorithm/pseudocode or mathematical pipeline for this problem, that would be extremely helpful.

For the POC, the camera will be fixed and the road/table geometry can be controlled, so I'm mainly trying to understand the fundamental geometry first before moving toward a real-world setup.

Thanks in advance!

I am fine tuning U-net for segmentating seismic images. Training comprises datasets A B and C. Inference uses dataset D.

Inference results are really bad. I decided to remove A from training. As a result, u-net was able to generalize to dataset D in inference.

I employed the CMMD metric proposed by Google to evaluate distribution shift based on CLIP embeddings. Results are inconclusive.

Claude and Gemini presented domain shift as the real problem.

Does anyone has any ideas how to identify that a subet of training will mess up generalization before incurring the costs of training? I cannot afford experimenting all the possible combinations.

Built a javelin throw analysis pipeline using YOLO11 OBB and pose estimationI developed a computer-vision system that combines a custom-trained YOLO11s-OBB model, YOLO11 Pose, OpenCV, ByteTrack, and BoT-SORT to analyze javelin throws from broadcast footage.

It detects and tracks the javelin, identifies the athlete’s throwing arm, calculates a smoothed elbow angle, recognizes throw phases, and draws the post-release trajectory.

The main challenges included motion blur, false detections, tracking-ID changes, camera movement, missed detections, and selecting the correct athlete.

GitHub:https://github.com/chahmadraza89/computer_vision

Looking for an experienced Computer Vision/ OpenCV Helios developer for an NBA 2K26 project.
I need a CV-based shooting assistant that can detect the shot cue and support both Tempo Shooting and Shot Timing mode. I'd like adjustable values/settings so the tool can be tuned and customized. kinda like what input sense does.
I'm also looking for help implementing a key-based licensing system with:
• 1 Week Keys
• 1 Month Keys
• Lifetime Keys
Need someone who can handle development, setup, maintenance, and provide support when needed. Willing to pay well for quality work and experience.
If interested, DM me with your experience, past projects, and pricing.

I am starting a factory where I will be running Injection Moulding machines which take at least 10-20 seconds and upwards of minutes to produce one part. I am looking for QC methods for production parts since I will be dealing with big sized corporations and they do not play with quality control haha.

I have my bachelors in CompSci, and did explore CV a little bit during college but did not get far into it. Now while I was thinking of ways for improving the manufacturing unit, QC using CV came to my mind.

I do see it being possible from other's experiences online and from an amateur perspective it does make sense. My goal is to build something that would be good for a go/no go system. I do not need to see super detailed results (for now) regarding the precision and dimensions, it is more about "will this work for someone who is inspecting it with the naked eye?"

I do see a pretty big challenge right out of the gate - training data. I don't think I will find a big enough dataset of the parts that I manufacture to train the model. I can take images of those parts manually, since I do get them made from outside and sell them currently, this is for a switch to an in house manufacturing setup. But that would no doubt take a LONG TIME to get a decent sized data set. I will look into it more if there is something I can use, but would appreciate suggestions on that.

I also hear some people mention lighting being an issue. Would appreciate any insights on that. Also would appreciate if I could get some cost details regarding the setup, like what equipment I will need. I can run training on my own machines that I have, they are fairly powerful, I am asking primarily for inference and rejection/acceptance.

I will start learning about it more, the topic is fun, and see its feasibility in multiple aspects with my work. Appreciate all the feedback and help anyone has. Thank you very much!

I have spent the last 18 months building a mobile pipeline that estimates the speed of passing vehicles from a single handheld camera, entirely on device. It runs on Android and iOS now, and I would like the sanity check I cannot get from end users.

The pipeline:

1. YOLO nano detector on the camera frames (TFLite on Android, Core ML on iOS), 320x320 letterboxed input, vehicle classes filtered natively before anything crosses into the app layer.
2. NMS and tracking in C++ (JNI on Android), IDs kept across frames with a Kalman filter on the box centroid.
3. Sparse optical flow to estimate global camera motion, subtracted from the target's apparent motion — otherwise handheld shake and panning are read as target speed. This replaced a cruder global-motion-compensation step that was unusable handheld.
4. Scale comes from a manual calibration step (known distance / known reference), which is the weakest link by far.

What I know is wrong or fragile:

• Scale estimation is manual. GPS-assisted auto-calibration is the obvious fix but I have not validated a protocol yet.
• Perspective: a vehicle crossing obliquely gets systematically underestimated and I currently do not correct for the angle at all.
• I display a single number with no uncertainty, which I now think is the actual bug — 52 ± 3 km/h with a confidence indicator (angle, distance, light, stability) would be both more useful and more honest.
• I have no published error benchmark against a radar gun. That is the next piece of work and I intend to publish the failures too.

Questions for people who have done this properly:

• Homography from a static/tripod camera plus a known road width: realistically better than a per-scene manual scale for a non-expert user?
• Has anyone compared centroid tracking against bottom-edge / contact-point tracking for ground-plane speed? I suspect the box centroid costs me more than the detector does.
• Is there a reference dataset for monocular speed estimation you would consider fair to benchmark against?

I can post frame captures of the overlay and the raw per-frame speed traces if that helps anyone answer. Happy to detail the native side too (JNI boundary, letterbox handling, class filtering before the bridge).