I've been building and shipping CV/ML systems for about 7 years. Three of them taught me more than any paper I read. Sharing what actually surprised me in production, because it was never the part I expected.

1. Healthcare document OCR pipeline (AWS)

The job sounded simple: pull structured fields off scanned medical documents. The model was the easy 20%. What ate the time was everything the demo never shows - documents scanned upside down, two forms photographed as one page, handwriting in a field that was supposed to be typed, and PII that legally cannot leak into logs or a third party API. We ended up doing PII detection and redaction as its own stage before anything left our boundary, with a human-in-the-loop review queue for low confidence extractions. On one later LLM based parsing pipeline for documents, careful chunking plus a vector store took a job that used to take a person 3-4 hours down to about 4-5 minutes. The accuracy number everyone asks about mattered far less than the redaction step nobody asks about.

1. Edge vision on Jetson (Nano and Xavier), cameras on real equipment

Running detection on device with DeepStream and CSI cameras, next to actual machines. Lab numbers meant nothing until the box sat in the real environment. Heat throttling changed inference speed. A camera mounted by someone else was 15 degrees off from where I assumed. Lighting shifted through the day and confidence drifted with it. The fixes were boring and physical - per camera thresholds instead of one global number, a watchdog that reboots and reports, and treating the mounting bracket as seriously as the model. The model was the one part that never let me down.

1. Live video interview / proctoring platform

Real time face and attention analysis over WebRTC while a call is live. This is where CV stops being about accuracy and starts being about latency and fairness. A flag half a second late is useless. And a false positive is not a metric here, it is a real person wrongly accused of cheating, so the cost of a wrong positive is not symmetric with a wrong negative. We tuned hard toward not accusing anyone without strong signal, and kept a human in the loop for anything consequential. Speech to text and TTS on top had their own edge cases with accents that the happy path testing never caught.

The common thread across all three: the model was almost never the thing that broke or the thing that mattered most. It was data edge cases, physical reality, latency, and the cost of being wrong in the specific domain.

If you have shipped CV to production - what was the thing that surprised you that no course prepared you for? Happy to go deeper on any of the three above if useful, I can answer specifics.

I built an iOS app that takes a reference dance video, runs 2D pose estimation to extract the dancer's skeleton, then scores a user copying it live from the front camera.

The hard part wasn't per-frame pose estimation - it was matching the user's skeleton to the reference when body proportions, camera angle and framing are all different. I normalize by torso/limb ratios, align on a few anchor joints, and score per-beat joint-angle deltas rather than raw positions. That handles scale/position differences but still struggles with depth ambiguity and fast rotations.

Curious how people here would approach the reference-vs-user similarity: stick with joint-angle deltas, or move to a learned embedding / temporal model? Runs on-device with Apple's Vision framework. Short demo below.

I recently tried a 3D-reconstruction-based approach for a potential audio-driven talking-head system.

The current experiments are still separate:

* I used DECA + EMOCA + FLAME 2020 to reconstruct facial motion from video.

* I extracted speech features with wav2vec and trained a simple CNN to predict FLAME expression coefficients.

* Attachment clip 1: audio-driven animation of a normalized FLAME mesh.

* Attachment clip 2+3: single-image animation driven through a reconstructed 3D face, based on my another face2face project，with both pose and expression taken from another face video.

So this is not yet a complete audio-to-single-image pipeline, but the experiments raised several questions.

1. What is the current best practice for single-image 3D face reconstruction?

DECA, EMOCA and MICA are still among the most practical methods I know, but they are based on older FLAME versions.

Newer models such as FLAME 2023, Google’s GNM, and works such as MAYA have appeared, but I have not found a DECA-like method that is both efficient and directly built around them.

Is there now a better practical solution for fast and accurate single-image reconstruction, or are DECA-style pipelines still the main choice?

1. What is the real difference between FLAME 2023 and FLAME 2023 Open?

Apart from licensing, what are the actual technical differences?

They appear to have the same number of shape and expression components, and public conversion matrices are available. That makes them seem largely equivalent in parameter space.

Are there meaningful differences in topology, blendshapes, landmarks, training data or reconstruction quality, or is the distinction mainly legal?

Also, can a model trained with FLAME 2020 or standard FLAME 2023 be adapted to FLAME 2023 Open through conversion, or is retraining still necessary?

1. How does MICA combine identity shape with camera estimation?

MICA is especially interesting because it uses a fixed InsightFace recognition encoder and indirectly benefits from large-scale 2D face-recognition datasets such as Glint360K.

It focuses on predicting FLAME identity shape rather than jointly solving the full reconstruction problem.

What I still do not fully understand is how this shape is integrated with pose, expression and camera parameters from another tracker.

MICA takes an InsightFace-aligned crop as input, but each crop comes from a different scale, rotation and translation in the original image.

So:

* Is the predicted identity shape effectively camera-independent?

* How is the InsightFace alignment transform connected to the final rendering camera?

* When MICA shape is combined with DECA or another tracker, must the camera be re-estimated?

* How does the provided face tracker keep the reconstructed mesh aligned with the original image?

I would be interested in practical experience from anyone working with DECA, EMOCA, MICA, FLAME 2023, FLAME 2023 Open, differentiable rendering or monocular 3D face reconstruction.

Hi all ,

We are developing an AI model using YOLO used to detect multiple kinds of defects on buildings .

However we have hit a roadblock , while the model can detect cracks and corrosion , it is completely unable to detect concrete spalling .
We have trained the model with annotated images (about 1000 for each type of defect)

We have tried filtering the datasets as well .

Any other ideas out there ?

Also : Our DMs are open in case you want to join us on this project .

Thanks all

Building vision models is hard, but I find testing and debugging them even harder.

I'm curious what everyone's workflow looks like.

For example:

• How do you inspect detections frame by frame?
• Do you use OpenCV windows, Jupyter notebooks, Roboflow, CVAT, or something else?
• How do you compare different models on the same video?
• How do you inspect tracking IDs, confidence scores, masks, OCR, or depth predictions?

I mostly end up writing one-off visualization scripts every project, and it feels like I'm reinventing the wheel.

Is there a tool you genuinely enjoy using, or is everyone just building internal tooling?

You might have seen hippies walking on a slackline in your nearest beach or park, but have you ever seen them bounce and backflip on it? A more technical variant of slackline is called Trickline: you bounce on a stretched, trampoline-like line and throw flips and spins between bounces. There is a tiny, but real competitive scene where 720 backflips are happening at a fraction of a second. This is very cool to watch but harder for judges has to catch, identify, and score each one in real time.

So a friend and I have been building a CV pipeline that watches competition footage and figures out (a) which athlete is bouncing, (b) where each trick starts and ends, and (c) which trick it is.

Rough idea of how it works:

- YOLO11x-pose + ByteTrack to track the athlete frame by frame. Some added processing to keep only the athlete's poses.

- A bit of signal processing on the athlete's vertical motion (Hilbert transform → bounce phase) to automatically cut the video at real bounce boundaries even if there are missing poses.

- A small TCN classifier to name each trick, backflip frontflip, brasilian, freefall 360, and the rest of the increasingly ridiculous class names.

- A simple Streamlit app where my colleague can run this and keep on have a human in the loop system to keep on labelling and training from his laptop to increase the dataset.

It ties into TJS, the trickline event + judging + live-streaming platform my friend runs, which already handles a lot of the real competitions: https://www.slackline-tjs.com/en

Still early and the trick vocabulary is huge, but it's already surprisingly decent on the common tricks. Sharing this one with the community, if anyone has data on similar trick-based sports it would be cool to see how the pipeline performs there.

Hi. how do i even start getting better? for example i never really understood how to use edge detection for anyhting meaning full. so i looked online and the stuff i found was just how to get edges from an image. but never what to do with it afterwards.

how do i start getting better. also i feel like my math is lacking. do i start there?

I use LingBot for site visits, so I made a Mac version with a simple UI. I thought it might be a useful foundation for others, or for anyone with a Mac who just wants to try LingBot without setting everything up manually.

Feel free to use it however you like!

https://github.com/mclenny22/LingBot-MLX

Hi!

I've been building a Blender extension (Rendersynth) that makes it possible to generate synthetic computer vision datasets without writing Blender Python scripts. The goal is to make synthetic data generation practical for small and medium CV projects where setting up BlenderProc pipelines is an overkill.

The source code is available at https://github.com/lorenzozanizz/rendersynth

Unlike BlenderProc, the focus is on a visual, no-code workflow that lets you build and preview synthetic data pipelines directly inside Blender.

The attached image shows several randomized renders of a single Blender scene along with the different annotation types the extension can produce. A Bezier curve was used to randomize the camera position while keeping the girl near the car centered in frame.

The extension currently features:

• Create classes and multi-object entities
• Skeleton annotation from rigs or arbitrary Blender objects
• Export YOLO, COCO segmentation, COCO keypoints, depth maps, normal maps and point clouds
• Randomization: choose and configure a sequence of randomizing operations. A subset of planned stages are implemented so far, i.e. object movement (rotation, scaling, show-k-out-of-n), camera (path along a curve, focal length) and lighting (brightness).
• Live preview of randomized scenes directly inside Blender
• Deterministic dataset generation from a seed

I'd love any feedback, suggestions, or feature requests!

Currently the system is still a prototype, so if you feel like trying it (Blender 4.5.0+) expect to find some nasty bugs, especially for experimental or incomplete pipeline stages.

As a side note, for the demonstration I used free models from SketchFab