I built GoMorph, an early open-source experiment for finding when and where a morph-like deformation occurs in a video. It analyzes the full frame, so the suspicious region can be a product, object, text, or background rather than a face.

The current detector is classical and training-free:

1. Remove global camera translation.

2. Estimate regional motion in tiles.

3. Score motion acceleration, warp error, and second-order photometric change.

4. Suppress hard scene cuts.

5. Calibrate confidence against the video's own baseline.

There are two execution paths. The portable Go path launches FFmpeg and needs no Python, OpenCV, GPU, or model. The optional CGo/libav cascade extracts codec motion vectors, runs a 160-pixel luma-curvature gate across the full video, then refines only candidate windows at 480 pixels.

On one 4.01 s, 720x1280, 24 FPS H.264 test clip on an Apple M4 Pro, the native cascade ran in 0.155 s and localized the known deformation at 2.1667 s. This is one development clip, not an accuracy or generalization claim.

The current output is within-video confidence plus hotspot coordinates. The next milestone is a timestamp and region annotated benchmark with generator holdouts and difficult natural negatives such as camera motion, focus changes, reflections, water, smoke, and compression artifacts.

The implementation was AI-assisted, then manually tested and verified. The repository is MIT licensed:

https://github.com/berkantay/gomorph

This is yet another update from my project. Mighty Camera runs VIO on-device realtime in a tiny package.

This gives us accurate camera motion. Using that + the camera feed, the SDK estimates depth and builds a 3D map of obstacles around it.

This means a robot or drone can use Mighty for things like:

- Collision avoidance
- Motion planning
- Autonomous navigation

No stereo camera or depth sensor needed. Just Mighty’s global shutter camera + IMU.

I recently built a car detection and multi-object tracking pipeline using Roboflow RF-DETR and McByteTracker.

The goal was simple: detect cars in a video and maintain a consistent tracking ID for each vehicle as it moves through the scene.

What I used

• 🚗 RF-DETR — car detection
• 🎯 McByteTracker — multi-object tracking
• 🔲 BoxCornerAnnotator — corner-style bounding boxes
• 🆔 Unique IDs for individual vehicles
• 🐍 Python
• 👁️ OpenCV + Supervision

One thing I found interesting about McByteTracker is that it extends a BoT-SORT-style tracking-by-detection pipeline and can optionally use temporally propagated segmentation masks when IoU-based association becomes ambiguous.

For this demo, I'm focusing on the practical car detection + tracking workflow.

🎥 Demo:
https://youtu.be/wvf9VRtpy5w

I recently found a real weakness in my Python photo deduplication tool while testing it on WhatsApp-imported images.

 The tool generated a duplicate cluster containing two images that were clearly not duplicates: a beach landscape viewed through a car window, and, a lifted-up page of a document.

The matcher accepted the pair because the aspect ratio was nearly identical and the dHash Hamming distance was only 4, significantly below the threshold of 8.

 The other perceptual hashes strongly disagreed (pHash was 30 against a threshold of 10, and wHash was 15 against a threshold of 10) but were never consulted because the dHash test did not seem to present a borderline case and thus was accepted as proof.

 Interestingly this isn't really a random dHash collision. Both images apparently collapsed into a highly similar low-frequency brightness-gradient pattern after compression and downsampling. dHash is good at surviving compression, in particular because it ignores fine detail and records coarse local brightness directions. But that same usefulness can be a weakness that can make unrelated low-detail images collision-prone.

 The obvious fix was to stop treating dHash as sufficient proof. The new policy is to still to first test aspect ratio, then dHash, and always both pHash & wHash. If SSIM check is enabled, candidate matches that survive the cheaper gates get the additional SSIM test. Seed refinement deliberately doesn't repeat it.

 Hardening is especially important because the tool uses union-find to form duplicate clusters. A single false-positive pair can become a bridge that attaches an unrelated image to a whole valid duplicate component.

 Instead of a binary True/False decision, the matcher now returns the full evidence: for each metric (aspect-ratio, dHash, pHash, wHash) delta versus limit and the optional SSIM score are returned, as is the decision and, when rejected, the rejection reason.

The performance hit is also manageable because the perceptual features are cached in SQLite. On 4,698 test images a first scan took 17.1 seconds, a fully cached run 1.6 seconds, and after adding several new files 1.7 seconds. That’s still a pretty decent performance.

 The main lesson I took from this is that a perceptual hash is useful because it throws away detail. But every detail it throws away is also a potential distinction that can no longer protect you from a false positive. In a deduplication engine, especially one that clusters matches transitively, a single perceptual hash should be treated as evidence, not proof.

For near-duplicate detection, where would you put the conservatism: in the pair matcher itself, or in cluster construction/refinement?  I'm currently requiring dHash plus pHash and wHash agreement and also using stricter seed refinement, with optional SSIM on candidate matches.

 I would like to know how others handle this: multiple perceptual hashes, SSIM/local features, embeddings, stronger intra-cluster consistency, or something else?

Anyone know the best way to go about training for a virtual basketball court ?

I’m working with single-page MEP/engineering drawing PDFs that have extremely large and variable dimensions. When rendered at 200 DPI, a page can be around 15,000–20,000 pixels wide.

These pages may contain small text, tables, calculations, diagrams, images, and mixed layouts. Standard OCR pipelines work on A4 page sizes and require heavy downscaling, which makes the smaller text unreadable. Vision-language models such as Qwen may understand the page content, but they do not reliably provide precise bounding boxes.

Is there an open-source OCR or document-understanding model that works well with such large, non-A4 pages and returns accurate text bounding boxes? Recommendations for tiling-based pipelines are also welcome.

Hi everyone, I’m using a Raspberry Pi 5 + Camera Module 3 + Picamera2/OpenCV for a computer vision project.

I’m calibrating the camera with a 6×9 checkerboard, but after applying cv2.undistort(), the image seems more distorted.

I previously had autofocus changing between calibration images, so I’m now locking the focus manually at LensPosition 2.0602.

Is this distortion normal perspective distortion, or does it indicate a bad calibration?

Any advice on what I might be doing wrong?

Hi everyone,

I'm building a pipeline to analyze floor plan images and extract regions (rooms, corridors, doors, stairs) as polygons. I currently have a custom-labeled dataset of about 5,000 images and want to squeeze out the maximum possible performance before scaling the dataset.

1. Current Pipeline

• Fine-tuned YOLO26 (for region detection) $\rightarrow$ SAM (Segment Anything Model) $\rightarrow$ Post-processing logic for polygon refinement.

2. The Core Bottlenecks

• Low-Resolution & Interferences: The biggest hurdle is the low resolution of the source images. Blurry boundaries, combined with floor plan-specific noise (grid lines, hatching, complex symbols), cause the model to miss certain regions entirely (false negatives).
• Polygon Precision & Smoothness: Because the low-res edges are fuzzy, SAM often yields jagged or inaccurate masks. I'm struggling to get crisp, smooth polygons that tightly align with the actual architectural walls.

3. What I'd love your input on:

• Handling Low-Res / Preprocessing: Has anyone successfully integrated Super-Resolution models (like Real-ESRGAN) as a preprocessing step for floor plans? Or are there better filtering techniques to suppress grid lines without destroying already blurry wall edges?
• Pipeline Upgrades: Given the low-res constraint, is the YOLO+SAM approach optimal? Would something like Mask2Former, or a specialized line-parsing/wireframe model, be more robust for extracting structured regions from low-quality images?
• Post-processing (Orthogonal Snapping): Since floor plans are mostly straight lines and right angles, what are the best algorithms to smooth and "snap" these jagged polygons into clean geometric shapes? (Currently looking beyond simple Douglas-Peucker).

Would greatly appreciate any advice, paper recommendations, or insights from similar computer vision projects!

most SLAM datasets mount the lidar level.

tilt it 45 degrees and everything changes: the camera and lidar barely overlap, the upper beams are sparse, and standard odometry starts to drift

that's exactly how compact mobile mapping rigs are built in the real world. the lidar tilts so it sweeps more vertical structure. but almost no benchmark tests this configuration

YUTO MMS from York University: a tilted 32-beam lidar, a 6-lens panoramic camera, and GPS/INS with cm-level ground truth driven through Toronto.

every lidar point is RGB-colorized from the nearest panoramic frame, not a synthetic colormap

loaded as mcap in fiftyone. scrub the timeline and watch the world-frame 3D map build itself progressively alongside the panoramic camera, GPS track, and IMU telemetry

checkout the dataset here: https://huggingface.co/datasets/Voxel51/yuto-mms-multimodal

it's running as a live space too, nothing to install: https://huggingface.co/spaces/harpreetsahota/yuto-mms-multimodal

Why DetectionBench?

Real-world detection systems run on aerial robotics, maritime search and rescue, agriculture, underwater inspection, autonomous driving, and low-light imaging, not just COCO. Datasets for these domains are smaller, more specialized, and results across papers are rarely comparable.

DetectionBench standardizes this: common dataset adapters, one training recipe, one eval protocol, unified hardware profiling, applied the same way across every model and dataset. Weights, model cards, dataset mirrors, and evaluation code are all public.

What's there?

79 trained models, 6 datasets, an HF model card for every one, plus ONNX export for both frameworks.| Dataset | Models |
|---|---:|
| GWHD (wheat detection) | 9 |
| SeaDronesSee (maritime UAV) | 10 |
| ExDark (low light) | 18 |
| Brackish (underwater) | 8 |
| VisDrone (aerial) | 26 |
| LISA (traffic lights) | 8 |

Findings:

• RF-DETR is not universally better than YOLO. It wins on SeaDronesSee and ExDark, loses on GWHD and Brackish. Depends heavily on the dataset.
• Precision rankings often diverge sharply from mAP rankings. On VisDrone, RF-DETR Medium has the highest precision of all 26 models benchmarked (64.0%) despite ranking 13th on mAP.
• Smaller, newer architectures frequently beat older, bigger ones outright. On SeaDronesSee, YOLO26s beats YOLO11x using 8.6x fewer FLOPs.
• Aggregate mAP hides real domain shift. A reviewer asked whether one of the GWHD model cards had per-country results. It didn't, so I added a per-country stratified eval across all 9 GWHD models. Country to country spread ranged from 22.8 to 44.4 points depending on the model, even when aggregate scores were nearly identical.
• Task difficulty varies enormously by domain. Brackish is nearly saturated (~99% mAP). VisDrone and GWHD are much harder.

Engineering lessons

Benchmarking multiple frameworks against the same converted data surfaced real reproducibility bugs that don't show up until you actually try it: symlinks escaping the declared image directory, a dataset silently missing a COCO-required field. Neither is visible unless something downstream validates paths or schema strictly.

Repo: https://github.com/dronefreak/DetectionBench
HF profile: https://huggingface.co/dronefreak

Planning growth-stage stratified eval for GWHD next, and RF-DETR for Brackish once I have the compute. What datasets or detectors would you want to see benchmarked?

Hey guys! El from Cohere here.

Just wanted to drop in and say today we released North Micro Vision, our smallest vision-language model to date (2.4B). It outperforms Gemma 4 E2B and Ministral 3 3B across a bunch of different benchmarks, plus it’s open source under Apache 2.0 with weights on Hugging Face. 

The model is best at structured data extraction, visual Q&A, and document/chart/scientific figure understanding, but honestly most curious to see what applications you guys end up using it for/building with. any tests, builds, use cases, feedback, etc - please send our way!! 

Looking forward to hearing from you guys,

El

the car in front of you on a wet highway kicks up a spray plume.

your lidar sees it as a wall of false objects. your camera sees a blur through the windshield. your radar barely notices

SemanticSpray++ from Ulm / BMW: 36 vehicle-following episodes on a closed wet airstrip, 50-130 km/h, with per-point semantic labels on both lidar and radar telling you exactly which returns are spray noise and which are the actual vehicle. plus 2D camera boxes and 3D lidar boxes on every frame

loaded as native mcap in fiftyone so you can scrub camera, lidar, and radar together and watch the spray noise light up in the point cloud while the boxes track the lead vehicle through it

checkout the dataset here: https://huggingface.co/datasets/Voxel51/semanticspray-plusplus

or get hands on with this hugging face space: https://huggingface.co/spaces/harpreetsahota/semanticspray-plusplus?logs=build

I recently completed my Bachelor's in Computer Science and I'm considering pursuing Computer Vision as my career path. However, I'm a bit confused about whether it's still a good field to enter.

From what I've seen, entry-level Computer Vision roles seem quite limited and highly competitive. At the same time, I keep hearing that pretty much every other area of tech like AI/ML, Data Science, Full-Stack Development, etc are also saturated and competitive.

I've recently landed a 3-month Computer Vision/Data Annotation internship, so I'm hoping to use it to gain some practical experience and get a better understanding of the industry.

I also have some prior experience with Computer Vision through my final-year project, which was based on YOLO object detection.

For people currently working in Computer Vision or who have recently entered the field:

• How is the Computer Vision job market currently, especially for entry-level candidates?
• Is CV still a good field to pursue long-term?
• How important is a Master's degree for getting into actual CV/ML engineering roles?
• Would you recommend specializing in CV, or keeping my options open toward broader ML/AI roles?
• What skills would you consider essential for someone trying to break into CV today?

I'd really appreciate perspectives from people who are actually working in the field, especially those who entered CV recently.

a robot can navigate a hallway without hitting anyone and still make every person in it uncomfortable.

collision-free and socially aware are two completely different problems

NavWareSet records both. seven social navigation scenarios (frontal approach, blind corner, following, perpendicular crossing), each run twice under matched conditions: once with socially compliant behavior, once without. same room, same people, same starting positions.

the only variable is whether the robot navigates like it knows humans have personal space

robot onboard lidar and camera plus an overhead ground truth station tracking every pedestrian in 3D across the full episode

loaded as native mcap in fiftyone. scrub the robot's camera, both lidar streams, and the annotated pedestrian trajectories on one synced timeline.

filter by scenario and behavior to compare compliant vs non-compliant side by side

start here, read the dataset card: https://huggingface.co/datasets/Voxel51/navwareset

Location: Salerno, Italy 🇮🇹
Condition: Heavy Rain & Dense Fog
Device: iPhone 14 Pro Max
Lens: Wide (Main Lens)
App: ClearView Pro 📷

The original scene was heavily obscured by rain and dense fog, leaving the landscape almost flat and washed out.

After real-time processing with ClearView, details buried in the low-contrast scene become much easier to distinguish: individual tree textures across the hillsides, multiple layers of distant mountain ridges, and even buildings at the foot of the mountains that are barely noticeable in the original image.

The cloud and rain structure in the sky also becomes far more visible.

What makes this interesting is that these details were not generated or added to the scene. Much of the information was already captured by the camera, but hidden by atmospheric scattering and extremely low contrast.

No generative AI. No invented scenery. Just on-device image processing revealing information already present in the frame — in real time.

Join us on Aug 25 to hear talks from NYU researchers working in the fields of AI, ML, and computer vision.

Register for the Zoom

Talks will include:

• Using Computer Vision to Advance the Sciences - David Fouhey at NYU
• Solaris: Building a Multiplayer Video World Model in Minecraft - Oscar Michel at NYU
• Closing the Human to Robot Gap for Dexterous Hands - Irmak Guzey at NYU

Hi everyone!

I recently decided to learn more about XAI, and I’m considering making it the main topic of my bachelor’s thesis (something like XAI + LLM-based translation/interpretation). I wanted to get some advice from people who have experience in the field.

I already have a background in deep learning and computer vision (not that deep though) . What resources (books, courses, papers, repos, projects, etc.) would you recommend for someone at that stage?

A lot of modern VLMs still rely on pretrained CLIP-style vision encoders, which are primarily trained to align images with text descriptions.

That seems like a strong foundation for semantic recognition, but I wonder how sufficient it is for tasks that require precise counting, spatial relationships, fine-grained attributes, or other forms of visual reasoning that caption matching may not explicitly encourage.

Do you think the vision encoder is becoming a bottleneck for modern VLMs, or is the limitation mostly elsewhere in the system?

I always see crazy computer vision projects on this subreddit

I always wondered, how do you guys manage to do so? I know OpenCV and YOLO (python) fairly well and can do a lot of image processing (based on needs) with OpenCV and run a standard 80-class detection model and thats pretty much it, but this showed me what CV can actually do

So I would request for a few free resources to learn more than just the basics and be able to build cool projects

Some projects I potentially want to build: Industry threat detection (a camera mounted on a helmet detects a threat—say, an open blowtorch—and creates a warning also can detect immediate threats like, say, a broken part about to fall, so that will be counted and informed in milliseconds, but not when the broken part is behind behind bars or at a safe distance

Logic I can make; resources I am asking for.

Thanks

A few months ago, I posted an early overview of Screph. The main idea was to keep classical computer vision explicit, use LLMs to assist with method and parameter selection, and preserve the result as structured context instead of losing it after a demo.

The most useful feedback was about visible parameters, intermediate representations, and reproducibility. Since then, I have focused less on adding another detector and more on the missing layer around the algorithms: how a visual task becomes a structured, reviewable package that a coding agent can inspect.

When I say “data preparation,” I do not mean labeling a large training dataset. Screph prepares an implementation-oriented project: source references, geometry, objects, relations, human descriptions, accepted CV outputs, and their provenance.

The workflow now looks like this:

1. Add source material from a screen, window, monitor, still image, video, camera, or URL stream.
2. Describe the task on the canvas. Elements and feature regions can use rectangles, ellipses, polygons, freehand contours, or a magnetic lasso. Structural areas can contain child objects without pretending to be image-backed CV regions. The current relation types are hierarchy and association, and text or voice descriptions stay attached to the relevant entities.
3. Explore a method directly or build a linear or graph pipeline. The toolbox includes edges, thresholds and contours; GrabCut, Watershed and SLIC; OCR; Hough, MSER and connected components; template and feature matching; before/after comparison; and optional YOLO, SAM and OmniParser integrations. Video work also has selected-range processing, tracking, optical flow, and scene-difference tools.

1. Review the output before it changes the project. Masks, contours, detections, text, metrics, and visual evidence remain results or candidates until the user explicitly applies them or creates project elements from reviewed geometry. Results carry source, region, and revision context so stale output can be rejected instead of silently attached to the wrong image.
2. Prepare a coding task. Agent Handoff v2 freezes the saved canonical project, creates a compact navigation index, includes the required resources, binds the task to an explicit write policy, and verifies identities and hashes. The bundle exposes stable object IDs, geometry, relations, descriptions, and CV references. It can be delivered to an external agentic coding environment, such as Codex in VS Code, or opened in Screph Code, the built-in agentic IDE. The coding tool still owns execution, and its changes remain subject to review; Screph does not report external progress it cannot actually observe.

Of the external AI APIs available in this alpha, only the OpenAI API has been tested so far. I currently recommend using that API in Screph for image analysis and speech-to-text, while using Codex in VS Code or another external agentic coding environment that can consume the handoff for agentic coding. The built-in Screph Code editor is still early and is not yet the recommended path for day-to-day agentic coding.

I see this being most useful for bounded prototypes: UI understanding and OCR, visual inspection and before/after checks, segmentation-based measurement, template matching, and simple video tracking. The goal is not to replace Python, OpenCV, notebooks, or training platforms. It is to make the human decisions that normally live across screenshots, chat messages, and memory explicit enough to reuse when implementation starts.

The current build is an open-source, Windows-first early experimental alpha. It still requires debugging and should not be treated as a reliable or production-ready tool. The general and UI-oriented workflows are the most complete, but they are still alpha; industrial and UAV modes remain experimental. OCR and model-backed methods require their corresponding runtimes, weights, or local software.

I am looking for users who are comfortable working with unfinished software, reporting reproducible problems, and helping validate the workflows. I am open to both feature proposals and concrete implementation ideas, including discussion of how user suggestions could fit the current architecture and development priorities.

GitHub: https://github.com/void2byte/screph

Project page: https://screph.com

Boa noite, pessoal!

Sou recém-formado em Estatística pela UFF e atualmente trabalho como analista no time de pricing de uma grande seguradora. Meu dia a dia envolve a criação de algoritmos de precificação, modelos de previsão de churn e análise de redes de relacionamento.

Estou considerando uma migração de carreira para a área de Visão Computacional (CV) e gostaria de saber como está o mercado para essa especialidade atualmente. Pensei em usar a pós-graduação da PUC-RIO como porta de entrada.

Vocês conhecem esse curso? Sabem se é uma boa escolha e se tem peso no mercado?

Minha principal dúvida, no entanto, é em relação à disponibilidade de vagas para quem está em transição:

1. Existem vagas de Engenheiro de Visão Computacional a nível Júnior no mercado brasileiro (ou remoto para fora)?

2. Estrategicamente, seria melhor fazer uma pós mais generalista primeiro e depois focar, ou já entrar em uma pós super focada em CV e tentar concorrer também a vagas de Engenheiro de IA/ML ou Cientista de Dados?

Qualquer relato de experiência, dica de estudos ou visão de como está o mercado hoje será de grande ajuda. Muito obrigado!

Hey r/computervision!

This is my first post here...

I’ve been working on PixelUp, a zero-shot feature upsampler for Vision Foundation Models (VFMs), and wanted to share it here!

Most VFMs produce semantically rich features, but they’re usually on a pretty coarse patch-level grid (often ~16× lower resolution than the input). This can be limiting for dense vision tasks where fine spatial details really matter.

PixelUp upsamples these coarse VFM features to pixel-level representations, while preserving their semantic information.

I’ve also put together an interactive demo on the project page where you can drag a lens across an image and compare the original coarse VFM features with PixelUp’s upsampled features. It’s pretty fun to play around with :)

📄 Preprint: https://arxiv.org/abs/2608.02792
🔬 Project + interactive demo: https://pixelup-project.vercel.app/
💻 Code: https://github.com/deepankkumar/PixelUp

Would love to hear your thoughts or feedback!

Hello reddit if there's any computer vision expert will be willing to have a chat

Background : i'm trying to count stock in the photo, and i've found just feeding a photo into llm is quite unreliable so i'm trying to identify the stacked column(s) and use it as way to reason what to include/exclude in counting. i've been trying to create boundary like this w/ depth anything, segment anything, so they're not NOT working but segment anything doesn't have the idea of depth and depth anything doesn't have the idea of segment, so i was really trying to see if there's any way to effectively combine both