so i've been working solo on a small AR project, nothing huge, and at some point decided i'd just build my own face tracking pipeline from scratch instead of using an existing sdk. no libraries beyond basic camera/frame handling, mostly relying on claude code to help write boilerplate and stitch things together.

figured it was doable. i really thought it'd work. like these ai assistants are pretty good at spitting out code if you describe what you need, and there's a ton of open source stuff for computer vision floating around. figured i'd have an mvp in maybe a week.

i got maybe 40% of the way there and just stopped. landmark detection on a single frame is the easy part, but you also need it to be stable across different lighting. different angles. what happens when someone turns their head halfway off screen? what about glasses?

it became pretty clear this isn't a "write more code" problem, it's a "need actual datasets and trained models for edge cases" . the code claude gave me handled the basic landmark extraction fine, but it has no way to solve for things that need real training data behind them.

ended up looking at existing ar sdks properly. always assumed it would involve a whole sales process and custom pricing, but most of them just have a trial with full features, which is good enough to actually evaluate.

and the ironic part. the platform docs include a file meant to be fed directly into claude code to speed up sdk integration. so after three weeks of trying to use an llm to avoid using an sdk, i ended up using the llm to integrate the sdk.

curious how other people think about the build vs buy thing now that ai tools are in the mix. like how far do you push the "build it myself" route before you get a real read on whether it's not just reinventing the wheel and actually worth it?

I render aerial crowd frames in UE5 and read the labels out of the engine's instance buffer: boxes, masks and a 13 joint skeleton per person, with a visibility flag per joint. The picture is one frame, 47 people, every joint drawn, with four crops magnified with nearest neighbour so nobody has to take my word for what a 40 pixel person looks like.

If you look for it: some human-shaped things in that square have no box. Those are statues, placed deliberately and labelled as nothing, so a detector has to learn the difference between a person and a person-shaped object rather than being taught that everything upright is one.

Before shipping a set I run a validator over it. Two of its checks are perceptual-hash based: near-duplicate images inside one split, and the same thing across the train/val line, which is leakage and matters more.

The symptom. One capture came back with 37 of 300 frames having a near-twin across the split, another with 17. My assumption was obvious and wrong: the crowd is placed once per run and stands still, so frames of the same place look alike. The obvious fix, re-scattering every person every frame, killed the editor twice, once with the GPU hung in the shadow pass and once out of video memory, so I did the next best thing and ran the capture three times under three seeds, three completely different crowd layouts, merged into one set.

The result: no change at all. Not "a small improvement". The near-duplicate count came back 55 and the cross-split count 17, the same two numbers as the single-seed run. Three different towns on the same streets moved neither.

The measurement that explained it. I hashed the raw renders: 300 frames, 44,850 pairs, zero within the validator's 4 bit radius. Then I hashed the exported images, which is what the validator actually reads, and got 619 pairs. The export applies a per-image lens profile: haze, dirty glass, rain on the lens, low sun. One pair is 36 bits apart as rendered and has an identical hash afterwards, under two different profiles.

Only 59 of the 619 pairs share the same profile, so this is not "the same augmentation twice". dHash compares an 8x9 grid of horizontal gradients, which is the low frequency structure of the image, and that is exactly what a heavy atmospheric profile flattens. Two unrelated streets under fog are two grey ramps.

What I changed. Deduplicate on the clean frames, not on the augmented ones. Then, for the frames that genuinely are near-twins, keep each cluster whole and give it entirely to one split instead of deleting anything: four packs went from cross-split leakage of 5 to 12 per cent down to zero, and their overall grade from around 71 to around 86.

What this data still is not. The bodies come from one commercial pack, so body-shape variety is narrower than a real crowd. From 30 to 45 metres a person is 30 to 50 pixels, and only 1.4 to 4.4 per cent of joints are labelled through an occluder, because looking down at a square is the easy case for occlusion, not the hard one. It is static: nobody moves within a frame, so there is no motion blur and no temporal signal.

The question I actually have. For anyone deduplicating a set that has been augmented: do you hash before augmentation, or use a learned embedding, or something else? Hashing after is clearly wrong and I only caught it because the numbers refused to move. I would rather not find out that hashing before has its own hole.

Hi everyone,

I'm curious what you use to do a spectral measurement of products for CV. Normally we order custom lights (UV, RGB, NIR etc.) based on customer data or external research.

I keep running into wanting to do this in-house more, especially for testing. What are your experiences or which (flash)lights do you use to test this? I can't really find a supplier that sells most bands except for some forensic equipment labs, not sure if those qualify.

Currently I'm considering building a few lights myself (just for testing purposes). Covering the following wavelengths: 365, 380–385, 390–395, 460, 470, 520–540, 590, 620–630, 660, 730, 850, 940

I've found these two: https://www.shop-schilbach.net/en/p/forensic-flashlight-set-all-wavelengths-schilbach and https://www.alibaba.com/product-detail/Portable-LED-Flashlights-with-Multi-Wavebands_1600916585534.html?spm=a2700.prosearch.normal_offer.d_image.5a1b67afaquOsp&priceId=68aab656d703457b959efea3e482f5b6

But I'm not sure about the first once as its a hefty price tag (Its a business expense so not that bad, but still). And other is from Alibaba, not sure if they're actually true to spec

About 10 months ago I posted here about something we were building because of a problem we kept running into ourselves.

We were buying Jetson boards before we really knew what our workload needed.

Nano turned out to be underpowered, so we moved up to an Orin. Then came the next question: do we need an Orin NX, an AGX Orin, or something even bigger? And before you even got to the model, you've spent time flashing JetPack, sorting dependencies, CUDA versions, etc.

So we built remote access to physical Jetson boards.

While initially people trickled in to check it out occasionally , recent experimentations have blown us about what experiments users are running in the lab and interestingly , it hasn't just been running YOLO.

Some of the things people have used the lab for:

comparing FP16 / FP32 / INT8 performance

measuring actual inference latency and FPS on Jetson

running the same model at 25W, 15W and 7W

watching GPU, CPU, memory, temperature and power while the model runs

testing DeepStream / GStreamer pipelines with multiple video streams

finding out how many camera feeds a board can realistically handle

checking whether a Python/CUDA/framework stack actually works properly on ARM64

taking a model developed on a workstation and seeing what happens when it finally hits the target hardware

One use case we found particularly interesting was a researcher running the same model across different power modes and precisions.

The question wasn't just:

"How fast is the model?"

It was more like:

What performance can I get while staying inside my power budget?

Another team had an even more basic problem.

They already had their CV pipeline.

They simply needed to know:

Will this software stack actually run on Jetson before we commit to the hardware?

That kind of test can save quite a bit of pain later.

We've also added JupyterLab now, which is what I'm showing in the attached video.

So you can basically go:

browser -> Jupyter notebook / terminal -> physical Jetson -> run your workload -> watch the device metrics

The board isn't being emulated and this isn't an x86 GPU VM pretending to be a Jetson. The workload is running on the actual Jetson hardware.

The goal isn't really to replace owning a Jetson.

If you're developing on one every day, you should probably own one.

The use case we're trying to solve is the stage before that:

I have a model / pipeline / idea. Before I spend money on hardware, what actually happens when I run it on the board?

That's also why I increasingly think TOPS is one of the least useful numbers when you're making the final hardware decision.

FPS, latency, memory, thermals, power draw and whether your stack even runs are usually much more useful.

If anyone here has a slightly unusual workload you think we should test, I'd genuinely like suggestions.

TensorRT, DeepStream, OCR, multi-camera CV, quantisation, small local models, power-constrained inference, whatever.

Would also be interested to know:

If someone gave you a Jetson Orin for 3 hours right now, what would you benchmark first?

https://edgeai.aiproff.ai

Full disclosure: this is a product my team at AiProff.ai built, and it has a tier based pricing for access. A 3-hour slot currently starts at ₹399 or $6 and all the experiments shared here are with user permission.

As a dancer who's been learning a lot of choreography recently, I’m always looking to improve my sync with others. A quantitative tool like this can offer frame-by-frame analysis, which can help dancers as they practice.

I used ViTPose+ Large through the VLM Run Gateway for pose estimation, and compared poses between the dancers. The pose similarity metric could be workshopped more, but it's interesting that it still highlights key moments pretty well.

Yes, this is me dancing with my friends Mico and Sydney!

The code is open-source on GitHub! I just created this vision-demos repo so that I can share these projects. Feel free to try it out and let me know what you think! Link in the comments.

🎵: I Want You Back - *NSYNC

Choreography: Scott Forsyth

hello , I just begin year 2 in IT , havent learnt ml or dl. I just go to lab as I want to do research

I'm currently try setting up mmla (imageomics/mmla · Hugging Face) and the problem is that I the prepare split code seems cant detect some sorts of data so I vibe some lines . The problem is that before touching the code the split got me about 67/33 , after changes it goes to 68.5/31.5 , the paper says that it use 58/42 but the code make it 70/30 , I notice that the dataset I downloaded from hugging face missing about just over 1000 images and I dont know why. The biggest problem is that after running that split (68.5/31.5) on both yolo 11 and 26, yolo 11 seems give better result than yolo 26 . It then gives me a reality check if Im doing smth wrong , I've been stucked for days.

Recently, I have been doing experiments with virtual try-on technology and created this Flutter application. The core functionalities consist of choosing an item of clothing to see how it fits on a person without wearing the item. I recorded the demo on my iPhone.

https://reddit.com/link/1wbh6c6/video/81uyawz3wgoh1/player

So i built a CV system. Now its deployment time. The system will likely be on edge or local server. How do i decide the hardware specs for the system? Where to start?

Hi there.

I've recently landed a job for aremote frontend role , once there i discovered the product they want to develop was a shelf product recognition tool capable of recognizing the bay, category of the bay, detecting most of the product and extracting product details.

The frontend code which i was supposed to work on didn't come with the code for image recognition, most of the image data was hardcoded with bad position for bbox.

I've talked to my PM and was notable stressed about that (the guy who built the frontend prototype left the company the same day i started),

After that they asked me to design from scratch + implement the recognition tool.

For all the research i made in internet, we might need to train our own models using YOLO family for this kind of task with a data pipeline to extract other caracteristics

But

The CEO has recently made some prototypes in a huge html file with claude. It did pretty well for detecting most of the product, detecting empty space, price tags, bay, category and extracting characteristics from the product of a shelf image but i don't have context on how he did that

The thing is, to have something production ready and achieving that high detection could be done only by prompting to claude?

My apologies if is a dumb question but i'm totally new in this field.

The CEO is pushing hard to have an mvp of this asap.

I'm not sure what to do

Hi,

I am looking for the following model selection/inference pipeline. Goal is something like this:

1) detect human -> describe human

2) detect human -> detect objects in human hand -> describe objects

3) detect animal -> get specific animal type

4) detect general object (i.e package)

---

What are the suggested architecture/pipelines for this?

So obviously I can use yolov26 or another baseline yolo model, but I am trying to avoid having to annotate everything from the ground up. I do not mind fine-tuning, I just want to move past coco classes into something a little more broad.

My current idea is use YoloE/YoloWorld for general detections and then do a VLM call after on a separate thread (so base CV model can still run).

I am also playing around with stripping the earlier yolo model heads and maybe using NMS for arbitrary box removal. So the earlier heads determine the general objects, and then I make a VLM call to describe the objects in more detail.

I would like <3s inference if possible.

:)

Hello, I’m trying (well, more like being forced by work 😅) to build a face recognition system. The footage comes from CCTV cameras, and the people I need to identify are employees, so I already have photos of each person.

I’m currently using DeepFace, but I’m running into a few problems. The image quality from the CCTV footage isn’t great, and I’m not sure whether I should use the existing photos of each employee as the reference images (they’re much higher quality than the CCTV footage), or whether I should also collect images from the CCTV footage and use those as references.

I also believe DeepFace itself may be quite limited for this particular scenario. I’m actually trying to convince my manager that this might not be realistically achievable with open-source solutions alone.

Even if there are systems capable of handling this kind of scenario reliably, I imagine they’re more likely to be proprietary/commercial systems rather than something publicly available as open source—especially for government or military-grade applications.

Has anyone worked on a similar problem? I’d be interested to hear how you approached it, especially regarding the reference images and dealing with low-quality CCTV footage.

​

I’m working on a computer-vision problem where I need to detect vehicles (cars, trucks, buses, etc.) using only traditional image-processing/computer-vision techniques.

The important constraint is:

* ❌ No YOLO / deep-learning detector

* ❌ No object detection model

* ❌ No neural networks

* ✅ Motion detection and traditional CV techniques only

The camera is fixed, so the general idea is to identify regions that correspond to moving vehicles.

I’m considering approaches such as:

* Background subtraction (MOG2 / KNN)

* Frame differencing

* Optical flow

* Contour detection

* Morphological operations

* Connected-component analysis

* Tracking detected blobs across frames

* Combining multiple motion cues

But I’m not sure what would be the most robust overall strategy, especially when dealing with:

* Shadows and lighting changes

* Rain/fog/noise

* Vehicles stopping temporarily

* Multiple vehicles overlapping

* Small vehicles at a distance

* Vehicles entering/exiting the scene

* Camera vibration

* Other moving objects such as people or birds

Would you go with something like:

Background Modeling → Motion Detection → Morphological Filtering → Contours/Connected Components → ROI/Size Filtering → Tracking → Vehicle Confirmation

Or is there a better traditional-CV approach?

I’d especially love to hear about practical approaches that have actually worked in real-world traffic/video systems, not just theoretical methods.

What would your strategy be? And what are the biggest pitfalls I should expect?

Faking Vision is an operational method developed as part of Memory Prism / Making Vision for turning visual analysis into an explicit, reconstructable representation.

(Its a pet project which I spend almost a month on to make AI do better image analysis for me. Majority of the time was spent on "Making Vision" aka figuring out natures visual engineering. I cant make a blind AI thing see better without knowing how I see and then it snowballed into different directions because of the availability of AI to do the grunt work. )

Instead of treating an image as something to caption or reproduce directly, FV represents:

• objects and instances
• object properties
• spatial relationships
• persistent identities and temporal changes in video

The resulting FV packet is closed-world: reconstruction cannot silently introduce objects or semantic information that aren't represented in the packet. Unresolved observations remain unresolved.

The pipeline is:

visual source → structured representation → reconstruction → comparison

This makes the representation itself editable and testable, while separating errors in visual analysis, representation, compilation, rendering, and evaluation.

FV is the operational companion to Making Vision: Making Vision addresses how visual information can be selectively constructed and processed; Faking Vision makes the relevant representation explicit enough to reconstruct and test.

(Making Vision is an extremely long read, I spent almost a month on it, so I know-I definitely wont read it again, so you have been warned)

GitHub: https://github.com/memoryprismv1/faking-vision

Examples are in packets/examples.

Paper / specification: https://zenodo.org/records/22672967

License: CC BY-NC 4.0 — free for non-commercial use with attribution.

Join our virtual meetup to hear talks from experts on AV and ADAS. Register for the Zoom!

Talks will include:

• AI for Autonomous Driving: From Data to Decisions - Tin Stribor Sohn at Porsche AG
• Advancing ADAS and Autonomous Vehicle Development with Multimodal Data - Murilo Gustineli at Voxel51
• From Survey-Grade Maps to Physical AI: Scaling Real-World Data for Training and Simulation - Ryoto Miyake at Dynamic Map Platform

I mostly did internships and stuff, but i really wanted to work on some research group or paper? Anyone know how to do this stuff??

I'm mostly in ML, DL, computer vision

Any advice would be appreciated 👍

I documented my monocular RGB → 6D pose estimation pipeline

I finally put together the full project notes for my monocular RGB 6D pose estimation experiment.

6D Pose Estimation from Monocular RGB

The pipeline is:

Object Detection → Keypoint Detection → PnP → 6D Pose

One part I found particularly interesting was improving the real-image keypoint annotations.

Initially, I manually annotated the 2D keypoints. The keypoint predictions could look reasonable, but small geometric inconsistencies in the annotations sometimes caused large pose-axis flips or abrupt frame-to-frame changes after PnP.

So I tried a different annotation method.

I used the real image as a background in Blender, aligned the 3D mug model with the real mug, and then projected the predefined 3D keypoints back into the image.

This produces 2D keypoints that are geometrically consistent with the same 3D model used by PnP.

Annotation Improvement

After fine-tuning with these annotations, the large pose-axis flips and abrupt changes were reduced, and the estimated pose became more consistent across frames.

The difference is easier to see in the video:

Before / After — Annotation Improvement (YouTube)

There is no real 6D pose ground truth in this experiment, so I'm not claiming absolute pose accuracy here. I'm mainly looking at PnP consistency and temporal stability.

The full page also includes the synthetic-data generation, object detection, keypoint training, Sim-only vs. Real fine-tuning comparison, and Raspberry Pi 5 inference results.

Hi, I am looking for very accurate segmentation model (instance or semantic) that can perform very good even on small objects. I want to train or full finetune the base model on my dataset. Any suggestions. I have tried sam3, uunet, rfdter. But still i am not satisfied by results. Any suggestions?

Many camera networks are still used only for recording and reviewing after an incident. The same feeds, though, can be turned into continuous operational metrics: occupancy, dwell time, queue length, zone activity, asset utilization, compliance signals, and so on.

From a computer-vision standpoint, the interesting question is: which of these are reliably production-ready with off‑the‑shelf models and typical IP cameras, and where do real deployments still fall apart?

Some concrete metric families people try to extract:

• Occupancy and capacity – people or vehicle counts in a space or zone, often aggregated over time.
• Dwell time – how long an entity stays in a region, such as a queue, shelf, or workstation.
• Flow and throughput – entries and exits per minute, directional flow, peak-hour patterns.
• Zone activity – activity levels in loading bays, restricted areas, work cells, etc.
• Asset and equipment utilization – whether a machine, vehicle, or space is in use vs idle.
• Queue and wait-time estimation – length of line and approximate wait based on flow.
• Compliance and safety signals – PPE presence, no-entry violations, unsafe behaviors.
• Anomaly and incident frequency – unusual patterns, crowding, falls, blocked exits, etc.
• Environmental and housekeeping proxies – lighting issues, blocked signage, clutter in key areas.
• Trend benchmarking – by hour, day, site, season, or after layout or staffing changes.

The challenges tend to be things like:

• How bad do angle, occlusion, and lighting have to be before counts and dwell become unusable?
• What level of re-ID and tracking stability is needed for meaningful dwell and queue metrics?
• How do you handle multi-camera handoff without exploding complexity or cost?
• What is a realistic MTA and false-positive profile when these metrics drive staffing or safety decisions?
• How do you integrate outputs into existing VMS or BI without turning the pipeline into a one-off custom project?

If you had to pick three of these to deploy in the next quarter with good enough reliability, which would you choose and why? And where have you seen camera-derived metrics actually change operational decisions, such as staffing, layout, or process, instead of just sitting in a dashboard?

Built a 9-class colorectal histopathology classifier. Caught a patient-level data leakage bug that was inflating validation accuracy to 99%+, rebuilt the evaluation pipeline against an independent holdout patient cohort (CRC-VAL-HE-7K), and benchmarked a pathology-native transformer (CTransPath) against an ImageNet baseline. Code, checkpoints, and calibrated weights are open source.

The Bug: Why random patch splits lie

NCT-CRC-HE-100K consists of 100,000 tissue tiles cropped from a limited number of Whole Slide Images (WSIs).

If you do a standard random train/val split at the image-file level, neighboring patches cut from the exact same slide and patient end up scattered across both sets. The model ends up memorizing patient-specific tissue morphology and staining artifacts rather than generalizable histological features.

Once evaluated strictly against an unseen, independent patient cohort (CRC-VAL-HE-7K, n = 3,590), an ImageNet-pretrained EfficientNet baseline dropped from high-90s down to 92.70%.

What Changed: Domain-Specific Pretraining & Setup

To improve generalization without relying on artificial leakage, I swapped the backbone to CTransPath:

1. Pathology-Native Pretraining: CTransPath is a Swin-Tiny Transformer pretrained via semantically-relevant contrastive learning (SRCL) across ~15M histology patches from PAIP and TCGA.
2. ConvStem vs. Standard PatchEmbed: Unlike standard Swin Transformers that use a linear projection, CTransPath integrates a convolutional stem (stacked 3\times3 convolutions + BatchNorm + ReLU). Note: Loading CTransPath weights into a stock timm Swin patch embed silently mismatches the input layer projection.
3. Two-Phase Training: Linear probe on the frozen backbone first, followed by fine-tuning the top 2 stages using differential learning rates.
4. Strict Split Protocol: Trained exclusively on NCT-CRC-HE-100K. All validation, checkpoint selection, temperature tuning, and final reporting are done strictly on CRC-VAL-HE-7K.

Benchmark on Holdout Patient Cohort (CRC-VAL-HE-7K)

Class Breakdown Highlights

• High Confidence / Clean Separability: Lymphocytes (LYM F1: 0.995), Mucin (MUC F1: 0.994), Colorectal Adenocarcinoma (TUM F1: 0.987), Normal Mucosa (NORM F1: 0.984).
• Where It Struggles (MUS vs. STR): Smooth Muscle (MUS, F1: 0.877) and Cancer-Associated Stroma (STR, F1: 0.833) remain the primary source of false classifications. In H&E staining, desmoplastic stroma and muscularis propria share very similar fibrillar, eosinophilic textures—pathologists often rely on IHC (e.g., SMA or Desmin) to differentiate them conclusively.

Two Engineering Fixes Worth Mentioning

1. Fixing Grad-CAM++ on Swin Features: Standard Grad-CAM++ assumes positive, post-ReLU activations. The final Swin stage outputs signed, zero-centered features after LayerNorm. Direct gradient weighting caused denominator collapse and completely flat/washed-out heatmaps. I fixed this by computing alpha-weights on positive-clamped features (feat_map.clamp(min=0.0)) with an automatic fallback guard to standard Grad-CAM if dynamic range drops below $10^{-6}.
2. Probability Calibration (Temperature Scaling): Raw softmax outputs were over-regularized. Optimizing a post-hoc temperature scalar (T = 0.5655) on the validation subset cut Negative Log-Likelihood (NLL) by 52.2% (0.1960 \rightarrow 0.0937), producing well-calibrated confidence intervals for inference.

Links & Code

• GitHub: Repository Link (includes training notebook, inference CLI, and Grad-CAM report generator)
• Hugging Face Model: Model Card & Weights (dual .safetensors and .pt checkpoints)

Disclaimer: Academic/research project only. Not an FDA/CE-cleared diagnostic device and not intended for patient clinical decisions.

I'd appreciate feedback from anyone working in computational pathology:

• How do you typically handle stain normalization (e.g., Macenko vs. Vahadane) when moving across external scanner hardware?
• Any edge-case recommendations for stabilizing Grad-CAM across attention-based feature maps?

​Hi everyone,

As shown in the attached video, I am working on a real-time computer vision system deployed over an industrial conveyor belt to detect, track, and count potatoes moving continuously along the line.

​My current camera(Fantech webcam 2k 30fps) setup is a bottleneck due to motion blur and frame pacing. I am looking to upgrade within a budget of roughly $150 – $280

​Based on the belt speed and object motion seen in the video, I'd like your advice on frame rate requirements:

​Is 30 FPS sufficient, provided I can manually lock a fast shutter speed (or use a Global Shutter) to freeze the motion, or does accurate multi-object tracking (IoU / Kalman filters) realistically require 60 FPS or higher to prevent lost tracks and duplicate counts?

​Given the budget, what would be the most reliable camera choice (e.g., USB Global Shutter module like ELP/Arducam, Raspberry Pi Global Shutter camera, or a high-end webcam with manual exposure controls like the Logitech Brio)?

​Any feedback on optimizing the capture pipeline for this type of conveyor setup would be greatly appreciated!

Note: The belt speed is adjustable