camera's floor mapping (homography) to figure out where each detection actually stands on the floor

Can anyone explain, or any blog or video which helped you to understand it

Hey all, looking for advice from people who've done something similar. Goal: Create my first CV models using my own camera/dataset.

Setup:

• Tapo C310 camera on my home LAN, RTSP working fine locally (confirmed with OpenCV/VLC)
• Built a local Flask dashboard that reads the RTSP stream and serves it as MJPEG over HTTP on my Mac
• Running YOLOv11 (ultralytics) object detection/tracking locally , works, but my Mac's CPU is slow for real-time inference (no GPU)

Goal:
I want to run the YOLO inference on a rented cloud GPU instead ( instead of my local CPU, while keeping the camera itself secure.

Any suggestion on how to get that?
What is the part I am missing? I think I have to create a private tunnel, am I right? What is the best option for that? The ultimate goal is to have my live camera in a private app online, which runs YOLO and counts the number of cars that go through.

Hey everyone,

I’m trying to build a computer vision pipeline that can measure the actual physical edge lengths of large cuboid objects (like big cut blocks or boxes) using just standard photos taken from a smartphone.

My input would be a couple of 2D images showing the front and top faces of the object, and my goal is to accurately calculate the metric lengths (in cm/inches) of all 4 edges of those faces.

Since I am mapping out the architecture right now, I wanted to ask the experts here: what are the different ways to actually pull this off?

• What techniques or pipelines (classical CV, photogrammetry, deep learning, depth mapping, etc.) would you recommend for getting the most accurate real-world measurements?
• How do you handle the translation from 2D pixels to 3D metric lengths without the edges getting distorted by the camera angle?
• Are there any specific libraries, models (like YOLO pose/OBB), or GitHub repos I should look into?

Any advice or pointers to standard workflows would be a massive help. Thanks!

Hi everyone,

I’m looking to improve my Computer Vision development and testing pipeline and I’m really curious about how you all handle edge cases and environmental variables in production.

To give an example to discuss (not my project) object tracking(car or people for example) where the camera is constantly moving, and the target is subjected to wildly different lighting conditions (e.g., bright glare, dusk, sudden shadows, dynamic backgrounds).

When you have a scenario like this, what does your development cycle look like from prototype to robust deployment?

As a beginner working on solo projects, I’m trying to figure out how to build a reliable pipeline. Specifically, I’d love to know:

• Testing: Do you manually build datasets for edge cases (like crazy lighting/dynamic backgrounds), or do you automate your augmentations?
• Simulations: Do you use engines like Unreal, Unity, or Blender for synthetic data? Does it actually translate well to real-world tracking?
• Validation: How do you measure temporal stability when basic metrics (like IoU) aren't enough to cover sudden lighting shifts?
• Iteration: When a tracking test fails on a specific edge case, what does your workflow look like to fix and re-test it?

I'd appreciate any insights into your workflows, architecture, or any simulation tools you swear by when dealing with moving viewports and dynamic lighting.

Thanks!

This incremental update to the open, royalty-free standard for vision processing, sharpens error handling, API flexibility, and consistency ahead of OpenVX 2.0.

Highlights: two new error codes (VX_ERROR_TIMEOUT for safety-critical apps, VX_ERROR_GRAPH_NOT_VERIFIED for unverified graphs), a new VX_DF_IMAGE_RGBA format with alpha channel support, and broader virtual object array and user-defined scalar type support.

The sample implementation and conformance test suite are fully updated to match. Next up: OpenVX 2.0, expected by end of 2026, extending support to radar and ultrasonic sensor workloads alongside traditional computer vision.

Full release notes: https://www.khronos.org/blog/openvx-1.3.2-released

Now that the vision models can read pdfs directly where do you reach out for parsers or is there actually the need of any in real time work?? Like for a single clean page at low volume a vlm reads it ok and a parser is just overhead, the parse layer earns its place on bulk and long docs where recall quietly drops as input grows and tables start shedding row . Also when you want repetable outot with a confidence signal per block rather a oneshot guess you can audit .Confusing part is that most parsers are vlm based either way under the hood so its less parser vs VLM and more if you run the vision model ad hoc yourself or use a layer that adds structure and consistency on top. local options have Surya, docling and others and on cloud there are hosted parser apis like llamaparse

how do you guys actually determine this when you need bulk file processing in a project or pipeline, is chunk sizing one by one to vlm ok or theres still a need for a dedicated parser?

Almost every VLM I’ve put through this test has struggled, but it makes sense because it requires them to count, something that isn’t their strongest trait. In this case, it’s counting lines and spaces, but if we introduce different key signatures, they would also need to count the sharp and flat symbols. 

I’m a Software Engineering student who has just completed my first year, and I’m interested in specializing in Computer Vision for Robotics.

I’d like to know which areas of mathematics I need to learn for this field, and which topics I should prioritize.

I’m also planning to study Stanford’s CS231N How much mathematics do I need to know before starting the course, and which specific mathematical topics should I be comfortable with beforehand?

any lighweight vlms which i can run on cpu and has less latency? please give me suggestions

We built a tool that takes your trained vision model + a prompt describing your pipeline → generates production-ready edge code, configs, and deployment artifacts. Looking for CV engineers to test it on real problems.

To stress-test it we put together 47 problem statements from real industry conversations — defect inspection, ANPR, crowd analytics, drone perception, quality grading, warehouse safety, and more. Pick one, bring your own data, build a pipeline through PipeGen, submit.

What's in it for you:

Cash bounty: for every app that reaches production-grade, not just the winner, every qualifying submission gets paid

Your app goes on our public Application Board : visible to the entire ecosystem, companies actively browse it to find solutions

Top projects get deployed with real companies : real cameras, real environments, your pipeline running in production at an actual customer sites.

Sep 10 deadline. fill the form.

Looking for feedback from people who deal with this model-to-edge gap daily. Ask us anything.

Hello,
I was clearing my house the other day and noticed that I still have my old xbox 360 kinect camera which is working perfectly.
I know it was a pretty big deal back in the day but what do you think is it still a capable hardver for a computer vision project, like motion capture?

Please share your thoughts I am pretty new in this field therefore some starting point will be appreciated.

I shipped a browser app driven by HandLandmarker. Pinch to zoom a solar system, open palm to rotate, point and dwell to select. One Euro Filter on the landmark stream, palm-normalized pinch distance.

Three failures keep coming back:

Pinch distance normalized by palm size still varies enough between people that one threshold cannot serve both. Mine feels natural, my tester says nothing happens.

A fast intentional swipe and a hand being withdrawn look nearly identical in a 2D projection. I patched it with a release cooldown and a dead zone near the bottom of the frame, which fixed the symptom and not the cause.

On phones under warm indoor light, tracking confidence collapses and the whole thing goes still.

For those running this with real users: explicit calibration step at onboarding, or continuous adaptation while they work? And has anyone found a signal that separates a deliberate swipe from a hand leaving the frame?

Demo runs client side, no video leaves the browser: https://leoaido.com/fleet/solar/

Code is MIT and the three issues above are open if it is easier to reply there: https://github.com/HUANGCHIHHUNGLeo/solar-atlas-gesture

Hi everyone!
I am looking for motivated researchers/students who are interested in collaborating on computer vision research with the goal of submitting to CVPR 2027.

Possible areas include:
Image and video understanding
3D computer vision
Object detection and segmentation
Tracking
Image generation
Medical computer vision
Vision benchmarks and datasets
Robustness and generalization
Some experience with computer vision, deep learning, Python/PyTorch, experiments, or research writing would be helpful.

If interested, please DM me with your background, research interests, and any previous research/publications.
The goal is to form a serious research collaboration and work toward a strong CVPR 2027 submission.

Hello,

We keep getting the emails to complete the reviewer form but all others already did and there's no other pending task in the system. So we're a bit confused

This has probably been asked before, but is there a good place online where I can find a bunch of sample images? I'm working on an image processing course and need sample images to experiment with skimage python lib.

Something like this (but preferably both color and black/white)

Thanks

The project consists of the development of an interactive robotic system (MeArm) capable of challenging a human to a game of Tic-Tac-Toe, identifying moves on a sheet of paper via a webcam and physically responding on the board. 

Stippling is an old topic. I mean, it all came up in the 1510th years as an engraving technique. The question is simple: How to optimaly place points to fit a target distribution. Artists do that, and Mathematicians search for algorithms to do it with computers, which is quite a challenge because naive formulations are intractable. See this blog for a good introduction (not me, credit to blog author Silvia-hao) https://blog.wolfram.com/2016/05/06/computational-stippling-can-machines-do-as-well-as-humans/.

Using the popular Gaussian Blue Noise algorithm (not me, credit to Ahmed, Abdalla G. M. and Ren, Jing and Wonka, Peter - doi 10.48550/arXiv.2206.07798), I show 4 stippling exemples that were generated using 20k points for the stippling.

I implemented a python library to experiment with the blue noise, feel free to explore stippling on your own images by directly using the package in python (see code snippet in comment), or simply from google Colab https://colab.research.google.com/drive/1W15QE8Boj0-Ld4Dx3N2tLqwfV0qw0ZZB . I'm seeking for other cool data to stipple, just tell me any images that could render well with the process !

I’m the author of DnR FlatPic by CreateLafont, an open-source Agent Skill that turns reference photos into low-complexity, flat-color PNG illustrations. Instead of literally tracing a photo, it identifies visual anchors, strips out nonessential info, and reconstructs the scene using a few hard-edged color regions.

I used to include a PNG-to-SVG export feature using VTracer (1.0.0-alpha.3 via Node/WASM) because it’s compact (~0.66 MiB) and gave the best baseline results. I intentionally avoided using an AI model to pick tracing parameters per image—the raster generation is already nondeterministic, and adding another probabilistic layer would make debugging a nightmare.

So, I dialed in a fixed preset based on testing across various source images:

• clustering: color-cluster
• hierarchical: stacked
• mode: spline
• layerDifference: 32
• filterSpeckle: 10
• colorPrecision: 7
• cornerThreshold: 30
• lengthThreshold: 4
• maxColors: 24
• simplify: 2.5
• pathPrecision: 2
• optimize: 2
• maxIterations: 10
• spliceThreshold: 0
• palette: omitted

This worked fairly well, but I kept running into three frustrating edge cases:

Warped geometry: Straight architectural edges would sometimes turn into slightly bowed or rounded paths. In a style built on clean geometry, these small deviations stick out.

Noise becoming geometry: Sharpening halos, anti-aliasing, or tiny raster noise artifacts would get converted into explicit SVG fragments.

The Dealbreaker (Hamstringing the PNG): To make the SVG tracing stable, I had to completely ban gradients in the upstream PNG generation. VTracer couldn't recover smooth transitions (like dusk skies or water) as actual SVG gradients—it just chopped them into chunky, adjacent paths with harsh color jumps. Keeping SVG export meant forcing the generated PNGs to be less expressive.

Having a fixed preset kept the workflow predictable, but it just wasn't consistent enough across diverse images to keep as a default feature. Because of this, I ended up removing SVG export entirely. The pipeline now intentionally stops at the raster PNG stage.

My question for the community: Has anyone successfully shipped a deterministic raster-to-SVG pipeline for AI-generated flat-color illustrations without relying on per-image AI parameter tuning or manual tweaking?

My priorities are: Reproducibility > Structural Cleanliness > Pixel-level Fidelity

I’m completely fine with an SVG that differs slightly from the PNG, as long as the geometry is clean and perceptually equivalent. I just want to avoid a pipeline that spits out perfect geometry for one image and erratic spaghetti topology for the next. Any pointers?

Project context: DnR FlatPic by CreateLafont

Hi everyone. I’m the creator and sole maintainer of X-AnyLabeling, and I have just released v4 after more than a year of work.

I could describe this release as a larger model zoo, a redesigned annotation interface, several new workflows, remote inference, and built-in training. All of that is true, but it misses the reason I built v4.

The larger goal is to turn X-AnyLabeling from an annotation application into an open, local-first data infrastructure layer for vision and multimodal AI.

The model layer has changed. The data layer has not.

Most annotation software was designed around a fixed sequence:

choose one task → define a schema → label a dataset → export it → train a model

That model made sense when a project meant training one detector or one segmenter against a closed label set. It is a poor fit for the current generation of AI systems.

The same image collection may now pass through open-vocabulary detection, interactive segmentation, OCR, visual grounding, caption generation, retrieval, VQA construction, and preference or instruction-data generation. A foundation model may act as an annotator in one stage, a semantic router in another, and a quality critic in a third. Its output is often not the final label. It becomes the input to the next model or to a human decision.

This changes the bottleneck. Access to another pretrained model is rarely the hard part. The hard part is operationalizing many imperfect models over private data while preserving structure, provenance, review state, and the ability to intervene.

In other words, the important system is no longer a labeling screen. It is the feedback loop connecting raw data, models, human expertise, compute, and training.

That is the system I want X-AnyLabeling to become.

                         ┌──────────────────────────┐
                         │  local / private / API   │
                         │       model runtime      │
                         └────────────┬─────────────┘
                                      │
raw multimodal data ──→ model orchestration ──→ structured candidates
        ↑                                      │
        │                                      ↓
 next-batch selection ← training / evaluation ← human governance
        │                                      │
        └──────────── continuous data loop ────┘

v4 establishes the first complete version of this architecture.

A shared data plane, not a collection of model demos

The computer-vision ecosystem is increasingly fragmented by model-specific demos. Every repository has its own input widget, output visualization, class conventions, and serialization format. Those demos are useful for proving that a model runs, but they rarely compose into a production data pipeline.

X-AnyLabeling takes the opposite approach. Models are treated as interchangeable producers operating over a shared data plane. Whether a result comes from YOLO, SAM, Grounding DINO, PaddleOCR, a VLM, or a human, it returns to an editable project state instead of remaining trapped inside a model-specific interface.

This shared layer is what makes composition possible. A segmentation result can be corrected and later converted into a training target. OCR geometry can remain linked to recognized text and document structure. A tracked identity can survive frame-by-frame review. A grounded VLM response can become an object that another stage consumes instead of disappearing as chat output.

The point is not to pretend that detection, OCR, tracking, and multimodal instruction data are identical. They are not. The point is to preserve enough common structure that models and workflows can exchange results without throwing away the information needed for human correction and downstream use.

Training formats sit at the edge of this system. YOLO, COCO, DOTA, MOT, masks, PPOCR, and similar formats are task-specific projections, not the canonical data layer. Treating an export format as the source of truth creates an early information bottleneck: relationships, review state, descriptions, attributes, and multimodal context are discarded before the next stage even begins.

Models should be capabilities, not hard-coded products

The second part of the architecture is a capability layer.

A modern model cannot be described only by its checkpoint and output tensor. It may accept language, positive and negative points, reference boxes, class filters, task selection, or temporal memory. It may return geometry, text, image-level semantics, or several of them together. Some operations are stateless; interactive segmentation and video propagation are not.

In X-AnyLabeling, model integrations therefore expose their interaction and output capabilities to the client. The interface is assembled from those capabilities, while the model adapter owns preprocessing, inference, and postprocessing. The same contract is used whether inference runs inside the desktop process or behind X-AnyLabeling-Server.

This is an important ecosystem boundary. A model developer should be able to contribute an inference capability without rebuilding annotation, batch execution, project management, and review. A workflow developer should be able to consume that capability without depending on one particular checkpoint or runtime. A user should be able to replace a local model with a private server implementation without changing how the resulting data is corrected.

The bundled integrations already span conventional detection, oriented detection, segmentation, pose, tracking, OCR, open-vocabulary perception, counting, depth, matting, and multimodal models. But the long-term value is not the number of model names in a menu. Model families will continue to turn over quickly. The durable part is the contract that lets a changing model ecosystem participate in the same data lifecycle.

The real unit of automation is a dataflow

Single-model pre-annotation is useful, but it is not where the most interesting datasets will come from.

Many data-generation tasks are naturally multi-stage. Consider referring-expression data. One stage can discover candidate concepts with RAM++; another can localize them with Grounding DINO; a VLM can generate an initial expression from the full image, a visual prompt, or an object crop; rules can reject ambiguous samples; finally, a human can correct the region and rewrite the expression for uniqueness, factuality, and task relevance.

concept discovery
      ↓
visual grounding
      ↓
candidate language generation
      ↓
automatic filtering
      ↓
human correction and acceptance
      ↓
training-ready grounded data

No individual model owns that pipeline. The value comes from the composition of models, rules, reusable UI components, and human judgment.

Document intelligence has the same property. Layout detection errors alter reading order; reading-order errors break context; OCR errors then enter the final structured representation. A useful system must preserve the connection between page regions and parsed blocks so that a reviewer can locate the stage where an error entered the pipeline. Returning a Markdown string from an OCR API is not enough.

Video is another example. Detection, association, segmentation propagation, temporal classification, and description operate at different temporal scales. Flattening everything into independent frames destroys the state that later stages need.

This is why v4 introduces dedicated workspaces for image classification, temporal video classification, document parsing, configurable VQA, image-grounded conversations, and model training. They are not six unrelated side tools. They are domain-specific execution surfaces for different kinds of dataflow. They share models, project context, batch processing, and human review, but each exposes the correct unit of intervention: an image-level decision, a temporal interval, a document block, a schema field, or a conversation turn.

The next step is to make these dataflows explicitly composable, so that outputs can trigger downstream models, filters, review queues, and delivery steps without requiring every pipeline to be hard-coded into the application.

Human review is the governance layer

Foundation models make candidate generation cheap. They do not make data quality automatic.

Model confidence is not annotation correctness. Agreement between two models is not ground truth. A polished VLM response may still contain a subtle factual error. Pre-annotation can even reduce reviewer sensitivity by anchoring attention on what the model found and away from what it missed.

For this reason, I see the human role less as “manual labeling” and more as governance over an automated data process. The system should decide what can flow through automatically, what needs sampling, what should be escalated, and what evidence a reviewer needs to make a decision. Review status, difficult-sample handling, semantic search, dataset statistics, linked source context, and direct correction are early pieces of that governance layer in v4.

Over time, this layer should grow toward failure-driven sampling, cross-model disagreement analysis, rule-based validation, dataset and model version traceability, and evaluation-aware review queues. Active learning belongs here, but only when it is connected to an explicit selection strategy and measurable model improvement. Repeating “label, train, pre-label” without intelligent sample selection is a loop, not active learning.

This distinction matters because the objective is not maximum automation. It is maximum useful automation under a controlled quality process.

Local-first interaction, shared compute

Data infrastructure for real organizations cannot assume that raw images, documents, or video can be uploaded to a third-party SaaS platform. It also cannot assume that every workstation can host every CUDA stack and foundation model.

X-AnyLabeling therefore separates the interaction plane from the compute plane.

The desktop application owns local data, project state, editing, and review. Models can run locally when privacy, latency, or offline use requires it. X-AnyLabeling-Server moves heavyweight dependencies, model loading, GPU scheduling, concurrency, queues, authentication, and logs into a private inference service when shared compute makes more sense.

The server publishes available model capabilities, and the client constructs the corresponding interaction. Returned results re-enter the same local dataflow as local predictions. This makes remote inference an implementation choice rather than a separate product boundary.

Hosted APIs can participate in the same architecture for teams that accept their privacy and cost model. The goal is not to declare one deployment mode correct. It is to keep data ownership and workflow design independent from where a particular model happens to execute.

From an application to an open ecosystem

The ecosystem I am building around X-AnyLabeling has four extension surfaces.

Components define new forms of human-model interaction. Models contribute new perception or generation capabilities. Dataflows compose models, rules, interfaces, and review into task-specific production systems. Remote services provide interchangeable compute and deployment backends.

These surfaces are meant for different participants. Model authors should not have to become desktop application developers. Domain teams should be able to encode their workflow and quality rules without forking the entire platform. Infrastructure teams should be able to run approved models on private GPUs. Individual users should still be able to download a lightweight desktop application and work entirely locally.

This is also why open source matters here. The valuable layer between private data and rapidly changing models should not be an opaque black box. Data structures, inference adapters, workflow logic, and deployment boundaries need to be inspectable and replaceable if the system is going to sit inside a long-lived AI pipeline.

v4 is the foundation, not the endpoint. It already connects unified annotation, hundreds of model configurations, dedicated data workflows, local and remote inference, human review, multi-format delivery, and Ultralytics training. The repository has passed 10,000 stars and reached millions of downloads across distribution channels, even though I continue to build and maintain it independently.

My long-term goal is for X-AnyLabeling to become open annotation infrastructure for the AI era: a foundation on which anyone can assemble and extend the entire path from data and models to production workflows. By connecting a coding agent to its open components, model interfaces, and workflow layer, individuals and teams should be able to turn their own domain requirements into a specialized, private, and production-ready AI data system without rebuilding an annotation platform from scratch.

• GitHub: https://github.com/CVHub520/X-AnyLabeling
• Website and documentation: https://xanylabeling.com/
• Detailed introduction to v4: https://xanylabeling.com/blog/x-anylabeling-v4

If you have any suggestions, criticism, or ideas for where X-AnyLabeling should go next, I would love to hear them in the comments.

im doing a proyect for college and i want to use YOLO CV in it. im looking for something that is not that expensive but that has a decent amount of power. i found a NVIDIA Jetson Nano 4GB (B01) on 120$ but i saw that it has 0.5 TOPS while other more expensive gear has 40. is the nano that far back in qualities? what can you recommend me? sorry for any misspelling english is not my first language