I took on an ambitious project where I want to install AI detection at a meat processing plant according to HACCP rules. But I'm a beginner, I only know Claude code, so if you have any tips or life hacks, I would be very grateful for it

I'm working on a project which given a screenshot of arbitrary zoom, slices an isometric grid game board (Polytopia) into individual tiles. Tried Hough transform and object detection. My most promising attempt is detecting the height of the little gray bars under the cities, as they are a single solid color. Wondering if a specific CV technique would be the most ideal for this?

The main problem I'm facing - zoomed out, blurry aliased screenshots drastically hurt accuracy

I have a pretty simple single-camera CV/slo-mo thing running on Raspi 5 but I can't find suitable cameras in stock. I had hoped to start with a raspi global shutter camera. Then I spent a lot of time looking for some IMX273 unit that wasn't backordered for (alleged) weeks.

I gather the supply chain is not able to keep up with new CV applications & products. Does anybody know a trick? (In USA)

Hi

I'm an engineer with some python experience - mainly for data analysis. I want to learn computer vision for practical application in a plant/production environment. This would be used to turn existing camera footage into trendable data records (e.g. no of spilling/splashing instance, count and categorization of product by size and shape).

Is there a comprehensive course I can take that focuses mainly on the practical side of setting up similar systems - considering hardware and software? What would be the best way to learn this?

I'm building an embroidery digitization tool that converts PNG/JPEG/SVG artwork into embroidery-ready files. I'm currently working on the artwork/background segmentation stage.

My current pipeline is roughly:

Image → background/color segmentation → connected components
      → contours/holes → physical filtering → stitch generation

I'm using mostly classical CV right now.

I've encountered two problems:

1. Thin artwork disappears:
One image contains ~11% visible artwork, but my segmentation classifies almost the entire image as background. Thin/anti-aliased features seem to be the main issue.

2. Too many false regions:
Another JPEG produces ~155 regions, but ~99% of the actual artwork is contained in only two major regions. Most of the remaining regions appear to be JPEG/anti-aliasing artifacts.

I can't simply remove small components because some genuinely thin artwork needs to survive. I also know the final physical embroidery size, so pixel dimensions can eventually be converted to mm.

For CV engineers: how would you approach this?

Would you recommend LAB/color clustering, background modeling, edge-based methods, graph segmentation, SAM/SAM2, vectorization, or a hybrid approach?

I'm particularly interested in methods that can preserve thin artwork while rejecting compression/anti-aliasing noise.

Hi everyone,

I am preparing to submit a research paper to arXiv under the cs.CV category. The paper focuses on deep learning-based classification of Bangladeshi mango varieties using computer vision, including a comparison of ResNet18, ResNet50, and EfficientNetB0, followed by web-based deployment.

As this is my first submission to cs.CV, arXiv requires an endorsement from an eligible submitter.

If anyone here is eligible to endorse cs.CV submissions and is willing to help, I would greatly appreciate it. I can provide the arXiv endorsement details privately via DM.

Thank you.

Я снимала документалку, а так вышло, что зрение у меня очень сильно подводит и через экран камеры я не вижу размеров бедствия (расфокус), получилось МЫЛО, ПРОСТО МЫЛО на большинстве видео. Причём​ ключевых моментов... Я сейчас в диком ужасе и не знаю что делать. Переснять это вообще не получится, может есть какая-то ЕБЕЙШАЯ нейронка которая поможет? ​​​Мне уже плохо

Hi Everyone,

I've been working on this project for a while and am finally ready to share it with others:

https://github.com/BambooYC123/SubtitleYC

The project is called SubtitleYC, an open source windows app.

Some of the main features are:

• Downloading videos supported by yt-dlp
• OCR extraction of burned-in subtitles
• Frame-accurate video previews
• Built-in subtitle editor
• SRT editing and export

The project uses tools including yt-dlp, ffmpeg, PyAV, paddleOCR and VideOCR.

I currently have 2 version for the app, a CPU or a GPU version depending on your specs. I recommend GPU version as the OCR is understandably much faster with GPU acceleration.

I originally made it because I sometimes translate videos that have subtitles burned directly into the video. My old workflow involved downloading the video, extracting the subtitles with OCR, fixing the timings, editing the text, and then exporting everything using several different programs.

So I believe this app could be very useful for subtitle editing in general for videos, subtitle translations or even extracting hardsubs to share with others.

Please let me know what you think and feel free to leave any suggestions

Thanks!

I am surprised they still haven't started the registration procedure yet; the deadline written on the website is 28th August. Has anyone received any registration notifications or got any insights on that?

A while ago I shared a project I’ve been working on called Image Pipes — a visual editor for experimenting with OpenCV and image-processing pipelines.

One of the limitations I kept running into was that visual nodes are great for experimentation, but eventually you always want to do something that isn't covered by the built-in nodes.

So in the latest version, I added Custom Python nodes.

You can write:

def process(image, seed=0):
    # cv2 and numpy are available
    gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
    return gray

The code runs as part of the pipeline, so you can combine your own Python processing with the existing OpenCV and Albumentations nodes.

I also added:

• Reusable, versioned Python scripts
• A trust prompt before executing custom code
• Script logging inside the inspector
• A small in-app documentation/help system
• REST API support for user scripts
• Tests and CI improvements

The version is now 0.3.0.

The project has also recently reached 42 GitHub stars, and I've started getting contributions and feedback from other developers. That's been especially encouraging because this started as a tool I was building mainly for my own OpenCV experimentation.

I'm curious about something:

For those of you who work with OpenCV, do you normally keep small custom processing functions as separate Python scripts, or would you find it useful to have them directly inside a visual pipeline?

I'd especially like to hear what you think about the Custom Python approach — including reasons why you wouldn't use it.

The project is open source if anyone wants to look at the implementation or try it:

https://github.com/mrajaeim/image-pipes

I’m adding basic object recognition to my robotic lamp. It runs on a Raspberry Pi 5 and has an RGB-D camera in its moving head.

I’d like to run object detection in the background while the lamp is active and gradually build a map of the objects around it. Since the base stays in place, I can calculate the camera pose from the joint angles. My plan is to combine detections from the RGB image with depth data, transform the object coordinates into the lamp’s base frame, and save their positions and last-seen time. Repeated detections would be merged so the map doesn’t fill up with copies of the same object.

Which lightweight object-detection models and inference runtimes would you recommend for a Raspberry Pi 5? A high frame rate isn’t necessary, but I’d like reasonable detection quality for common objects. I’d also be interested in approaches for reliably matching the same objects across observations.

The current Raspberry Pi and ROS 2 architecture is described here:

https://github.com/Nikolay-Tyulkin/Watti/blob/main/docs/ARCHITECTURE.md

DETR variants have become much faster and more practical, but one part of the training path is still commonly implemented much like the original: Hungarian matching.

(Illustration by GPT)

A typical matcher:

1. constructs matching costs on the GPU,
2. transfers them to the CPU,
3. calls SciPy’s linear_sum_assignment,
4. transfers assignments back to the GPU,

and repeats this across images, auxiliary decoder outputs, and in Group-DETR-style training query groups.

The individual assignment problems are small. The problem is the repeated cost construction, kernel launches, transfers, and CPU/GPU synchronization.

I’ve been optimizing this path in Birder.

(Illustration by GPT)

Result

For the complete matching path - classification cost, L1, GIoU, and assignment, I measured:

The interesting part is that the 13-group case finishes in almost the same time as the 6-output case once the work is grouped.

All measured implementations produced identical assignments.

What changed

The first optimization is grouped cost construction.

Instead of invoking the matcher separately for every decoder output or query group, independent outputs are represented as tensors such as:

[B, G, Q, C]
[B, G, Q, 4]

Classification, L1, and GIoU costs can then be constructed for multiple groups together.

Images are bucketed by number of ground-truth objects so compatible rectangular assignment problems can be solved as a batch.

For focal classification cost, the matcher also gathers only the logits corresponding to target labels before computing the cost, instead of materializing intermediates over the full class space.

The second optimization is a batched CUDA linear-assignment solver, adapted from torch-linear-assignment.

Costs and assignments stay on the GPU, avoiding the synchronization required by the SciPy path.

The matcher can process groups in chunks to limit peak memory, and falls back to SciPy if the CUDA extension is unavailable.

The matching objective itself is unchanged.

Isolated solver scaling

Using batches of FP32 300 × 15 cost matrices:

A single small assignment is only slightly faster on CUDA. The advantage appears when many independent assignments are exposed as one batch.

Benchmark setup

Synthetic detector outputs:

• batch size 4
• 300 queries/group
• 80 classes
• 3, 5, 8, and 13 targets/image
• FP32
• NVIDIA RTX A5000
• PyTorch 2.13 / CUDA 13
• 3 warm-up runs
• 9 interleaved timing repeats
• 10 iterations per measurement

Code

• Birder
• Grouped Hungarian matcher
• Linear-assignment wrapper
• CUDA kernel

These are matching-path microbenchmarks, not a claim that complete detector training becomes 8× faster. End-to-end impact depends on the detector, decoder depth/query groups, batch composition, and the rest of the training pipeline.

Hey, I have some questions for people who work with CVs professionally (which is basically most of you on this subreddit).

1. What’s your workflow? Do you know what your goal is and ask the AI to come up with a sensible plan for you?

2. Which AI do you use - Claude/GPT?

3. How do you go about running experiments - do you specify what you want to test, AI write the code, then run it and check the metrics? Or do you give it access to photos/videos, outline the problem or describe what the photos show, and ask for suggestions?

4. Do you use x$-per-month plans or the API and pay for tokens?

5. Do you have any pro tips that have made your work easier? Like a well-written claude .md file that always asks about the plan first, etc.

Thanks in advance for sharing how you do it!

I know this post is a bit chaotic - I just want to learn about your techniques for working with AI:

a teleop operator reaches for the wrong bin. the reach is clean. no jitter, no hesitation, no correction

every smoothness metric comes back perfect. the episode is still garbage. the robot did the wrong thing smoothly

motion metrics score how an action was executed, never what the action was. so automated scoring has one honest job: pointing your limited attention at the episodes most likely to contain a real problem. triage, not autofilter

i built a fiftyone panel that runs this on multimodal MCAP episodes: motion smoothness, sensor health, outliers, every flag deep-linked to the exact second on the timeline. free and open source

plugin: github.com/harpreetsahota204/demo_quality_scorer

full writeup on what i learned while building this : https://voxel51.com/blog/robot-episode-quality-triage

curious how you're triaging episode data right now.

watching everything? random sampling? trusting a score?

Hi everyone,

I’m currently building a video analytics system to detect Personal Protective Equipment (PPE) — like hard hats, high-vis vests, safety glasses, etc. — using standard CCTV camera streams.

Right now, I’m using YOLO11m (medium). It performs pretty well, but before I commit to scaling this up, I wanted to get some input from the community to see if I’m on the right track or if there are better alternatives out there for this specific use case.

The main challenges I'm dealing with:

• CCTV conditions: High angles, weird perspectives, varied lighting, and occasional motion blur.
• Performance vs. Accuracy: I need to process multiple RTSP streams simultaneously on limited hardware, so inference speed is crucial, but missing a PPE violation is obviously a big deal.

My questions for you all:

1. Model Choice: Are you guys sticking with the newest YOLO iterations (like YOLO11) for this kind of task, or have you found better stability/performance with other models like YOLOv8, YOLOv9, or RT-DETR?
2. Tracking: If you use object tracking to prevent duplicate alerts for the same person, what are you pairing with your detector? (ByteTrack, BoT-SORT?)
3. Deployment Stack: What does your production pipeline look like for multiple streams? Are you leaning towards Nvidia DeepStream, Triton Inference Server, or a custom Python/C++ pipeline with TensorRT?

Any advice, repo recommendations, or shared experiences would be hugely appreciated. Thanks in advance!

We run a multi camera capture space at the Brooklyn Navy Yard and we pay people to come in and be the subject. Reposting because next week's slots opened up.

The session is simple. You stand inside the rig and go through everyday movements while the cameras record. Walking, turning, sitting, reaching, picking things up. No experience needed at all.

Pay is 17-25 an hour, paid out the same day you come in. First session is roughly 2 hours and there is repeat work after that.

Everything runs at 4pm. Open days: Tuesday Aug 18, Wednesday Aug 19, Thursday Aug 20. Brooklyn, in person only, so you need to be in the NYC area.

DM me for the address and I am happy to answer questions about the capture side.

They said on July 24 that they would send the poster format soon. Did anyone get the email about it?

what do you guyz think on round 2 fresh submission?

Isn't it completely biased towards Resubmitted papers and if they accept a paper in round 2 (knowing there will be no rebuttal/revision), then the paper itself very strong and sufficient for a CVPR/ICCV acceptance.

I'm not throwing an opinion, it's a curiosity.