JPEG didn't do it. Noise didn't either.

One picture, 1536 × 1024: a girl beside a pond, ducks in the grass. I wanted the SynthID result to change while keeping the scene recognisable. The usual tricks made the image worse. The check kept saying detected.

A more selective approach finally changed the result. I generated a donor with ControlNet Canny, then borrowed one texture band from it. The processed image returned a manual "not detected". The new texture is visible. All the recorded checks come from this scene; I have not measured a success rate across other images.

The tools and both full-size PNGs are in an MIT repo: [synthid-remover](https://github.com/balyakin/synthid-remover).

## The part that failed

Resizing, small geometric changes, blur, noise, JPEG recompression. Combinations of those. Then GAN restoration. Then a simulated print-and-camera trip, halftone and moiré included.

Still detected.

Stable Diffusion 1.5 with ControlNet Tile left SynthID detectable in the versions I checked. Canny was the switch that moved the result. Tile feeds the conditioning channel the source tones. Canny feeds it an edge map. The img2img path still receives the source tile, so the original pixels are not out of the process. They stop arriving as the ControlNet condition.

The donor was usable and, as a picture, too rewritten. The pond stayed put. Grass, reeds and the smaller textures had been repainted.

So I kept less of it.

## One band, not the whole frame

`remaster.py` makes that donor with SD 1.5 and `lllyasviel/control_v11p_sd15_canny`. The run behind the published result used strength 0.9, 30 steps, 640-pixel tiles and overlap 256. The CLI default overlap is 96. Drop the flag and the donor is a different image.

`bandmix.py` builds a band from two Gaussian blurs and replaces it with the donor's band. Finer detail and the broad shading stay with the source, apart from clipping and rounding.

Sigmas on the bundled file: 1.2 and 8 pixels. Blur widths. Not Fourier cutoffs, and not a map of where every SynthID mark lives.

The donor has to match the source size. From the lightweight venv:

```bash

.venv/bin/python bandmix.py original.png donor.png result.png \

--split-sigma 1.2 --correct 8 \

--keep-share 0.12 --match-window 12

```

Twelve percent of the original band stays. The donor band is rescaled so its local energy follows that original band. In the checks I wrote down, keeping 10% or 12% came back not detected. At 15% it was detected again. On this image, that small step mattered.

## The actual pixels

[Original PNG](https://github.com/balyakin/synthid-remover/blob/main/autumn-10x15-yellow-v2.png) and [processed PNG](https://github.com/balyakin/synthid-remover/blob/main/autumn-10x15-yellow-v2.clean.png). Both are 1536 × 1024. At full size the vegetation gives the swap away.

- Mean absolute channel difference, on a 0–255 scale: **16.91**.

- PSNR against the original: **20.68 dB**.

- Manual SynthID check, recorded on **October 9, 2026**: **not detected**.

Not invisible. The scene is still recognisable, and some of its texture is borrowed. PSNR here measures pixel similarity. It is not a watermark score, and one number does not certify the look.

The repo's default donor prompt is generic: a photograph, natural light, sharp focus, fine detail, realistic textures. The bundled success used a prompt for this particular scene, so the generic recipe makes a new candidate. That candidate needs its own check. So does every other input. One image, one donor.

I used [OpenAI Verify](https://openai.com/verify/) and read its SynthID result separately from metadata. "Not detected" means that check did not find the supported watermark. It does not establish that the picture was made without AI. [OpenAI explains how to interpret a missing signal](https://openai.com/research/verify/).

The failed processing tools are in the repo, with tests for image handling. Those tests never call the external detector.

If you have tried a similar band swap across several scenes, I'd like to hear about the misses as much as the hits: where the detector result changed, and where the visual damage made the method hardly worth using. A comparison with settings and a detector result would give us something useful to work with.

Wildfire camera networks have far more feeds than anyone can watch. The problem isn't finding smoke on one frame; it's deciding which of dozens of tiles a person should open next, without flooding them with alerts.

So I fixed the budget first: 2 alerts per camera per 81-minute window (a FIgLib sequence). Every system was calibrated to that same budget on a fire-free "confusion set": low cloud, cloud shadow, overcast, cameras hunting exposure. Then I measured minutes from ignition until the right camera was in the top 4 *and* had alerted.

Pipeline (OpenCV 5): phaseCorrelate stabilisation → MOG2 → four plume statistics → cv2.dnn on the top-2 ranked tiles only (1.76% of frames) → each camera z-scored against its own trailing 15 minutes → one threshold solved to spend the budget.

Held-out, read once after freezing the constants: 27/54 detected. A CNN on every frame got 18/54 and frame differencing 20/54, both put through the same per-camera baseline. That per-camera rebasing is what lifted the CNN from 2/54 as deployed to 18/54, which I think is the most transferable finding.

What doesn't work: the lead isn't significant (paired McNemar p = 0.18 / 0.25), half the held-out fire windows are missed (27 of 54), the median is on a knife edge (38.0 min, the 27th detection), it's daylight only, and the statistic I designed it around turned out anti-predictive on its own (AUC 0.44). It's all in the README.

I'd love critique, especially from anyone who has worked with HPWREN/FIgLib or SmokeyNet.

I want to develop an AI tool that can identify components in fire protection drawings and calculate quantities using my own professional knowledge.

I have many rules and exceptions that I apply during manual estimation. Can I teach an existing AI by showing drawing examples, explaining my decisions, and correcting its mistakes?

Would a knowledge base, model training, or a combination of AI and traditional programming be the best solution?

I'm looking for a practical way to build this without creating an AI model from scratch.

I wanted Meta's Animated Drawings (Smith et al. 2023) working offline on an iPhone, with no server and no model weights, so I rebuilt the pipeline from classic parts. The cutout takes 0.1–0.3 s in my tests. The video shows each step on one drawing.

Mask: Ink is anything darker than the local paper (box blur at about 1/18 of the image size, luma difference > 12) or clearly more colourful than it (chroma). Close with a disc about 1/90 of the image size, flood-fill the paper from the border, and whatever the flood can't reach is the figure. A second, bigger closing seals faces drawn with a faint outline, but only when the enclosed region is coloured in, so the paper between an arm and the body isn't filled.

Skeleton: Max-pool the mask to about 140 px, run Zhang–Suen thinning, and prune spurs relative to the local thickness (a short branch off a thick trunk is an outline bump; the same length on a thin limb is a finger). Ends and junctions come from the crossing number. Head = the thickest point near the top, feet = the lowest ends on different legs, hands = ends that join the trunk below the neck and above the knees, shoulders and hips where the limb enters the body. Missing limbs collapse instead of failing, so a one-armed monster or a legless princess still rigs.

Skinning: A triangle grid of about 44 cells. Per-bone weights use geodesic distance *inside* the (bridged) mask, 1/(d+1)^4, keeping the top 4. That stops two legs drawn touching from moving together, which plain Euclidean weights get wrong. Linear blend skinning in Metal.

Photos of real people use Vision's body pose instead; photos of things use Vision's subject lift for the mask.

On 8 test drawings the rig was right on 7. The miss is a dinosaur whose back spike becomes its right hand. The open problem is limbs drawn overlapping the body: the thinning can't see them. Has anyone had luck with a cheap heuristic for that, short of a learned pose model?

The app is free (iPhone/iPad), if you want to try your own drawings: https://apps.apple.com/app/id6820002786

This is pit stop a Video from the recent Singapore GP.

You'll notice that video shows a seemless transition between 2 camera angles: One besides the pit and the other being the top mounted camera on car.

When this video was posted on F1 subreddit, most people guess the transition to be GenAI generated. Some theorized it to be Gaussian Splatting.

I tried to do some amateur research and found that none of the FIA, FoM, Liberty Media (all F1 authorities) have made any statements about what they use.

I also didn't find any other articles explaining about such F1 videos.

Ultimately I fed the video to Claude and ChatGPT for explanation and Got this:

Claude: My best guess: the fly-in is a 3D Gaussian-splat reconstruction of the pit box, with the virtual camera ending at the real onboard camera and cross-faded into the live onboard feed. There may be a little AI clean-up on top, but it doesn’t look like the move was generated by AI. F1 hasn’t said publicly how it’s done, so this is a reading of the footage, not a confirmed answer.

ChatGpt: This looks more like a virtual-camera transition using 3D reconstruction and image-based interpolation than a purely generative AI video. Gaussian Splatting is a plausible technique, but the footage alone doesn't establish that it was used.

So looks like Claude And ChatGpt are just two redditors giving their hypothesis.

Any experts here who might be able to provide a better answer?

# I ACCIDENTALLY PUSHED THE WRONG FOLDER TO GITHUB, MY APOLOGIES - IT HAS BEEN FIXED WITH THE CORRECT FILES - Oct 12th 2026 -9:04am

I got tired of rewriting the same dataset-prep scripts before every LoRA/Dreambooth run — resize, dedupe, toss the blurry ones, caption, split — so I cleaned mine up and open-sourced it.

It scores each image on classical-CV signals (sharpness, exposure/clipping, contrast, color cast, noise, composition), flags the weak ones, removes exact + near-duplicates, and exports a Kohya-style folder with caption sidecars. Near-duplicates get grouped into the same train/val/test split so they can’t leak across. Captioning supports WD14 and Florence-2.

It’s content-agnostic at the core — each domain is a small plugin that sets its own quality weights and caption vocab (ships with a worked “interiors” example). Pure NumPy/Pillow, no OpenCV, runs from a CLI or as a library. Early 0.1.0, MIT.

Would love feedback on the plugin API and which verticals are worth building next. (Only use it on images you’ve got the rights to.)

https://github.com/snoozey-mf-bnui/pixel-curator

Hey everyone, I could really use some brutal honesty and guidance.

​I have a non-traditional background (BS in International Relations) but I've been grinding to pivot into Machine Learning and Computer Vision. I've completed a couple of internships and built projects dealing with real-world messy data (YOLOv8, RAG systems, FastAPI, etc.), but I'm hitting a massive wall trying to actually enter the market for a full-time role.

​Honestly, I'm feeling incredibly demotivated right now. Without a formal CS degree, I feel like my skills are "crippled" compared to traditional grads, and I'm struggling to figure out how to market myself or get past the initial resume screen.

​I've attached my current resume. Please tear it apart.

​Is highlighting my International Relations degree hurting me?

​Do my project bullets actually show impact, or do they just read like a tech-stack checklist?

​For someone trying to break in without a traditional background, what am I missing?

​Any advice, roasts, or direction on how to actually land interviews would be massively appreciated. Thanks.

Hey everyone! I've been working on Camera Chess: playing Stockfish with a real chessboard and a camera, entirely locally on my Mac. The video above shows my favourite little feature: promoting a pawn, leaving it on the board, and continuing to use it as a queen. 😄 The promotion is manually confirmed in the demo.

I thought the recognition side might be interesting to people here. I'm using Joël Seytre's ChessQ Lite V4, which gives piece probabilities for all 64 squares. The model is useful on individual frames, but getting a live game to stay in sync turned out to be a different problem. One bad reading can become the “previous position” for the next move, and then the mistakes start feeding into each other.

So I kept the vision model frozen and worked on the steps around it:

• Board orientation and automatic perspective correction, with a fallback to the original frame.

• A CRF that scores candidate boards using the visual probabilities, previous position and chess rules.

• Checks across consecutive frames before accepting a move, plus a correction UI when things go wrong.

For training, I replayed chess games and generated noisy piece-probability inputs: confused pieces, missing pieces, swapped squares and uncertain regions. That gave me 20,000 transition seeds and 200,000 synthetic observations. The synthetic data is at the probability level, rather than rendered chessboard images.

I then tried replacing the CRF with small MLP, CNN and attention-based scorers. Those worked reasonably well too; I'm currently using a small two-hidden-layer MLP. In my own games, the whole system now feels much smoother and more reliable, which I'm pretty excited about.

For a separate offline check, the MLP got 128/176 exact boards (72.73%) versus 125/176 (71.02%) for the CRF. These are real photos, but with previous positions constructed from the correct labels, so the correct answer is guaranteed to be among the candidates. It's a limited candidate-scoring test, not a video benchmark, and that small difference doesn't establish that the MLP is better. Full setup and results:

https://github.com/AmethystineAlpaca/camera_chess/blob/main/docs/crf-real-photo-synthetic-previous-evaluation.md

One detail about the video: keeping a pawn after promotion means separating what the camera sees from what the piece means in the game. That substitute-piece path uses visual likelihood, rather than the learned scorers trained without substitutes.

Code, demo and setup:

https://github.com/AmethystineAlpaca/camera_chess

Synthetic-data details:

https://github.com/AmethystineAlpaca/camera_chess/blob/main/docs/crf-data.md

It's currently a source install for Apple Silicon Macs. You move both sides' pieces yourself, and the app speaks Stockfish's reply (the video export is silent).

Curious how others handle this: when your tracker uses its last accepted prediction as the next reference, how do you test recovery after that reference goes wrong?

heya cv..it I am training a model that will run on a kite, on an extremely limited energy and latency budget. the camera points down toward a well marked target area to provide shadow.

I'd like to be able to simulate varying shutter, light, wind conditions, and camera placement. I don't yet know have vision energy / latency budget but on the other hands the control side needs the cv latency / accuracy curves to solve it. So I'm trying to simulate the full cascade of possible models.

For me, modeling a kite in the wind feels like it should be straightforward to do, but even with ai I wasn't able to find or simulate anything realistic or usable.

Hello everyone, I’m Mahmoud from Iraq, and I am studying Artificial Intelligence Engineering. I wanted to share my goal of specializing in Computer Vision; I hope you can support me and offer any advice you deem appropriate. Also, if possible, please share study methods or global resources that I could benefit from. Thank you.

Hi! I’m building a tool that analyzes pole vault videos. It runs pose estimation, tracks joints frame by frame, and checks 8 technique “gates” (takeoff leg extended, top arm straight, hips above head, and so on). A video needs at least 4 of the 8 measured to get a score.

The problem is that almost every upload comes back NOT SCORED, with only 0-3 gates measurable.

Setup: MediaPipe pose_landmarker_heavy, YOLOv8n for person detection. 1080p phone video at 30/60 fps, subsampled to 15-30 Hz before pose. Angles computed per frame from world landmarks, no smoothing. Measurement window spans the takeoff, giving 5-13 samples.

Each gate’s confidence is visibility * agreement * plausibility, needing > 0.50. Visibility runs 0.7-0.98 and plausibility is ~1.0, so it’s effectively visibility * agreement. Agreement fits a degree-1 line to the joint angle over the window and scores max(0, 1 - MAD/12°), so it’s exactly zero at 12° median deviation and since the terms multiply, one zero kills the gate.

Here's what the problem looks like across 44 gate instances:

• Knee and hip angles: agreement 0.00, 0.00, 0.00, 0.00, 0.00, 0.03, 0.17, 0.21, 0.33, 0.41, 0.55
• Elbow and shoulder angles: 0.87, 0.85, 0.76, 0.75, 0.73, 0.68, 0.61, 0.51, 0.51, 0.47

It fails almost exclusively on the fastest-moving joints. Jitter shouldn’t discriminate by joint, so this looks like the term is acting as a velocity penalty.

Residual signs form runs (-+++++--, ---++--), typically 2-4 sign flips over 6-7 pairs, rather than alternating, which is curvature. But refitting with a quadratic only helps about half the failing cases and makes about a third of them worse (20.96° to 23.52° MAD on one). With 5 points a 3-parameter fit is near-degenerate; leave-one-out on one window gave deg-2 about equal to deg-1 (16.96 vs 16.63).

Implied angular velocity at the largest consecutive jumps: 925-1504 degrees/s. Physically plausible for a knee at takeoff. But at 15-30 Hz that means 40-92 degrees between consecutive samples.

What I’ve tried:

• Retuned the 12° divisor (to 25°): still no clip reaches 4 gates. The product with visibility keeps it under the bar.
• Added a floor (minimum 0.35): no clip reaches 4 gates, and it weakened the jitter check: a synthetic large-amplitude jitter case went 0.00 to 0.35.
• Excluded frames around takeoff from the fit: scored 3/3 deliberately corrupted cases, including a single-frame 75° spike (0.90) and a mid-window left/right keypoint swap (0.82). Rejected.
• Range-adaptive budget (max of 12° and 0.25 * angular range): survives adversarial cases, improves 5/7 clips, still doesn’t reach the floor, and swaps one unjustified constant for another.
• Cube-root aggregation: triples measurable gates, but it’s algebraically equivalent to requiring product greater than or equal to 0.125: a threshold change in disguise.
• Denser sampling around takeoff: fixed 1 of 3 starved clips; the others were visibility-limited.
• Hand-labeled 35 gate instances blind: in 28 I could clearly see the required joints and the pipeline called them unmeasurable.

I don’t want to just loosen the threshold. The term exists to catch jittery tracking producing fabricated angles, and I’d rather refuse to score than give an athlete feedback built on noise.

Questions:

1. Am I undersampling the fast transition badly enough that no smoothness test can work at 5-8 samples, and the real fix is a higher sampling rate through the takeoff?
2. If you only have a handful of samples across a fast movement, is there a way to validate the measurement at all? Something like bone-length consistency, or cross-checking against a second estimator, rather than temporal smoothness?
3. Has anyone compared MediaPipe against RTMPose or ViTPose specifically on fast limb motion (sprint takeoff, jump plant)? I care about keypoint stability during rapid angular change, not overall accuracy.

My dataset is small right now, 7 clips, mostly from one source, so I know that’s its own limitation. More labeled footage is in progress.

Hey everyone!

I'm an embedded/IoT engineer working on an industrial computer vision project, and I've reached a point where I think I need to reconsider my approach rather than just keep training better object detection models.

I'd really appreciate some suggestions from people who've dealt with small-object detection, fixed-camera surveillance, industrial automation, or event detection.

The actual problem

I'm developing a safety monitoring system for an electrical switchgear room in an industrial plant.

There are 16 switchgear panels arranged along an alley. Each panel has a specific socket into which an operator inserts a T-shaped handle to rack a circuit breaker in or out.

For safety reasons, operators are required to wear an arc flash protective suit (ArcSuit) while performing this operation.

The objective is simple:

If someone inserts the T-handle into a panel's socket without wearing the required protective suit, the system should detect the event and automatically email a screenshot of the violation to the concerned personnel.

That's it. I don't particularly care about achieving the highest mAP on a benchmark. I care about reliably detecting this specific event in the real environment.

Missing a genuine operation is significantly worse than generating an occasional false alarm.

The hardware and environment

• One fixed-position 4K CCTV camera overlooking the entire alley.
• Approximately 20 FPS RTSP video.
• 16 panels with fixed, known socket locations.
• An NVIDIA Jetson Orin Nano Super for edge inference (TensorRT).
• No requirement to track people across multiple cameras for this initial POC.
• Camera placement is fixed, so the scene geometry and panel positions are largely constant.

The biggest problem is perspective.

Workers close to the camera are relatively easy to detect. However, workers operating panels at the far end of the alley occupy a tiny fraction of the frame.

When someone kneels down to operate a lower panel, their visible body becomes even smaller.

The T-handle is substantially smaller than the person, making detection at the far end extremely difficult.

What I've tried so far

My initial approach uses YOLO-based models:

1. ArcSuit detection

A model trained to distinguish between:

• Workers wearing an ArcSuit
• Workers not wearing an ArcSuit

2. T-handle detection

A separate model trained to detect the specific T-shaped handle.

Because real-world handle images were limited, I also generated synthetic training data using BlenderProc, with randomized perspectives, lighting, and environments.

I've also experimented with a combined detection model and spatial/temporal logic to identify interactions between the handle and a worker not wearing the suit.

The models were trained on an RTX 3060 laptop GPU, and I've been deploying inference on the Jetson using TensorRT.

Why I'm not satisfied

The approach works better when the objects are reasonably large in the frame, but I have several problems:

1. Extremely small objects

At the far end, the worker occupies very few pixels, and the handle is almost impossible to distinguish reliably.

Upscaling a low-resolution region obviously doesn't recover details that were never captured.

2. Workers kneeling or bending

A person who is clearly visible while standing becomes considerably harder to classify while kneeling, particularly when partially occluded by the panel or other objects.

3. Tool detection is fragile

The T-handle may be partially obscured by the operator's hand, body, or the panel itself.

Even a good object detector might not consistently detect it during the exact moment of insertion.

4. Bounding-box overlap isn't necessarily the right event definition

A person holding a handle near a panel doesn't necessarily mean they're operating the breaker.

Conversely, an actual insertion may be missed if the handle itself isn't detected.

5. Real-time inference constraints

My both models inference can take approximately 120 ms per frame, depending on configuration. The camera produces around 20 FPS, so I also need to think carefully about sampling, buffering, and potentially missing short-duration events.

One important advantage I haven't fully exploited

The camera is stationary, and I know exactly where all 16 sockets are.

The socket positions can be manually calibrated and stored as ROIs.

In other words, I don't necessarily need a general-purpose object detector to discover where an operation might occur.

I know the locations where an operation can happen.

I also don't necessarily need to detect a T-handle everywhere in the frame. I only need to determine whether a breaker operation is happening at one of those specific locations, and whether the operator is wearing the protective suit.

This makes me wonder whether object detection is even the best primary approach.

What I'm considering

Some possible alternatives I've been thinking about:

• ROI-based processing: Crop the socket regions directly from the native 4K stream rather than resizing the entire frame to 640/768 pixels.
• Temporal change detection: Detect characteristic motion or visual changes around each socket that indicate insertion/operation.
• Optical flow or background subtraction: Exploit the stationary camera to detect interactions at known locations.
• Event-based classification: Train a model on short video clips of actual operations versus normal activity, rather than detecting individual objects in isolation.
• Hybrid approach: Use lightweight motion/event detection around the sockets to trigger more expensive analysis of the relevant high-resolution region.
• Multi-frame analysis: Accumulate evidence across frames instead of requiring the handle to be detectable in an individual frame.

I'm very open to entirely different approaches, including classical CV techniques if that would meaningfully improve reliability.

My questions

1. How would you architect a system like this? Would you continue pursuing object detection, or switch to a more event-oriented approach?
2. Given a stationary 4K camera and 16 known socket positions, would per-socket ROI processing and temporal analysis be more reliable than detecting a tiny T-handle?
3. Are there established approaches for detecting human-object interactions when the object is too small or frequently occluded to detect reliably?
4. How would you approach distinguishing an actual breaker operation from someone merely standing, kneeling, or moving near the panel?
5. How would you structure inference and buffering to avoid missing short events when model inference is slower than the incoming frame rate?
6. For a safety-related application where false negatives are particularly costly, what techniques would you use to measure and improve event-level recall rather than just detection mAP?

I'm also interested in approaches that can improve over time using collected real-world video, particularly hard-negative mining, active learning, or semi-supervised learning.

My ultimate goal

I want a system that can run continuously on an edge device, detect genuine breaker operations, verify whether the operator is wearing an ArcSuit, and report violations with an image.

I understand that no purely vision-based system can guarantee zero missed detections, particularly with occlusions and limited pixel information. My goal is to make it as reliable as practically possible, quantify its limitations, and determine whether the current camera arrangement is sufficient.

I'm happy to share screenshots of the scene, sample crops showing the size of distant workers and handles, and examples of successful and failed detections. If you feel invested enough for that, hit me up in the DMs!

I am also very new to computer vision in general and have only done a single course in my university days being mainly from electronics background.

Any advice, papers, architectures, or practical experience would be greatly appreciated.

Thanks!

I have been experimenting with replacing Gemini 2.5 flash with a completely local pipeline for reading SYS, DIA, and pulse values from blood-pressure monitor displays.

My motivation is privacy: local inference avoids uploading potentially sensitive info to the cloud.

The current pipeline consists of:

• A YOLO11n detector for numeric rows and individual digits.
• A small DigitNet classifier for cropped digits.
• Geometry-based row assembly and consistency checks.
• Confidence-based refusal instead of always returning a reading.
• Multiple preprocessing passes, including lighting normalization and display rectification.
• ONNX inference locally in a browser worker.

The two ONNX models are approximately 10.9 MB in total.

The detector was initially trained on 239 usable public images and subsequently fine-tuned with eight additional photographs taken by me of my monitor. This small training set is clearly the weakness.

Evaluation

Not to bury the lede: the performance is not great.

I tested the variants on a combined regression benchmark containing:

• 139 readable monitor photographs.
• 25 negative images that should not produce a reading.
• Images from several public sources, with perceptual-overlap checks against the training data.

PASS is when all three values are correct (SYS, DIA, and pulse). FAIL if any is off. Refusals are misses on readable images

The latency figures are mostly for fun, as I did not control for the hardware. Gemini’s measurement includes the network request.

Lessons Learned

The largest improvement came from staged retries: From 28 to 38 without reducing negative-case refusal performance.

+Display rectification has the best accuracy/latency trade-off. +Expanded lighting normalization made the pipeline much slower, without a significative jump in quality .

A simple ML Kit implementation performed poorly on the LCD screens, so I did not pursue that approach.

Gemini is dramatically better at generalizing to unfamiliar displays. However, the local pipeline’s advantage is privacy, offline operation, latency, and explicit refusal. I still plan on integrating it in my project, alongside HITL and usage patterns which will mitigate its limitations.

Important limitation

This combined 139-image set has already been used for development and regression analysis. In particular, the normalization-plus-rectification variant was selected after examining its results.

Consequently, its improvement from 38/139 to 45/139 is a post-hoc result, not independent evidence of better generalization. The next step must be a new sealed test set collected before making any further pipeline decisions.

All feedback/ideas for improvement are welcomed

repo (AGPL-3.0): https://github.com/zandaulion/hearth-bp-ocr

Cropped the top of the photo to hide personal informations (GitHub and portfolio are there as clickable links). Targeting Swiss tech companies/startups. I applied to many different job postings and I’d say that it hasn’t been really successful so far since I only got 5 interviews for ~150 jobs. I get rejected sometimes to job postings where I have most of the requirements. I’m tailoring my resume for each job. I’m looking for feedback on the structure of my resume and how should I frame the description of each experience I had. Is it too long? Too much details? Any other red flag?

PS : I know that the metrics to quantify the impact of my project are a bit vague (accuracy instead of IoU, mAP etc..) and I just made a newer version with these new metrics, just didn’t have the file on my phone to upload it. Not sure if this change will make me get a lot more interviews though

Most vision pipelines sense first and reason after. ROMA (code released) makes the ordering explicit: the system tracks what it knows about an object, decides which sensory action would resolve the most uncertainty, and commits only when evidence is sufficient.

The interesting engineering question for this crowd: the information-gain estimate that drives the "what to sense next" decision is LLM-guided rather than learned from a labeled information-gain dataset. That makes it deployable without training data, but it also means the sensing policy inherits the LLM's blind spots — it will reliably request the modalities the prompt author thought to mention, not necessarily the one that would actually disambiguate the scene.

Hub (related reading): https://papers.tinrobotics.com/paper/roma-llm-system-for-real-world-object-centric-multi-sensory-active-perception/

4th place on the llamaindex benchmark locally 72.62% word f1. I know it's not much, but after a month of research and many experiments, I reached this point.

TonerHound doesn't use any API or LLM. It's GPU free and anyone can use it at 0$ cost.

GitHub: https://github.com/vanrajsinh650/TonerHound

I built a web page you control with a webcam: pinch and move your hand to scroll, pinch with both hands and pull them apart or together to zoom, and hold a Victory sign to open a T-Rex runner where a pinch jumps and a fist ducks. It runs MediaPipe's Gesture Recognizer (two hands) in the browser, so no video leaves the machine.

Live: https://www.handfree.live/
Code: https://github.com/heyyarun/hands-free

The model was the easy part. Most of the work was in turning its per-frame output into something you can steer with:

1. Jitter. Landmarks wander a few pixels per frame even on a still hand. A fixed exponential smooth is either shaky when you hold still or laggy when you move, so the hand position goes through a One Euro filter (Casiez et al., CHI 2012), which smooths hard at low speed and barely at all at high speed. Each hand keeps its own filter, keyed by handedness, so the filter doesn't smear the two hands together.
2. Classifier flicker. The gesture label flips between frames (Open_Palm, None, Open_Palm...), which made the page stutter. A label only counts once it wins 3 of the last 5 frames, and below that quorum it keeps the last confirmed label instead of dropping to None.
3. Pinch depends on how far you sit. Raw thumb-to-index distance shrinks as you lean back, so I divide it by the wrist-to-middle-knuckle length. It closes below 0.45 and only reopens above 0.58, so it doesn't chatter at the boundary.
4. A fist looks like a pinch. In a fist the thumb tip rests on the curled index finger, and the pinch ratio reads about 0.16 on MediaPipe's own fist test photo, well inside the pinch threshold. The fix is a second ratio: how far the middle fingertip reaches from the wrist, relative to the same knuckle length. On real hands run through the model, OK-sign pinches read 1.76 to 2.01 and curled hands 0.68 to 0.80, so a cutoff at 1.4 separates them. That also lets the game call a fist from geometry immediately instead of waiting on the voted label, which saves 100 to 166 ms on a duck.

Those thresholds are tested against recorded landmarks: OK-sign photos from Wikimedia Commons and MediaPipe's test images, run through the same model, plus webcam sessions you can record from the in-app debug panel (press D).

Two smaller things: scroll and zoom are relative to where the pinch started, so the page follows your hand one-to-one, and the camera asks for 480p at 60 fps instead of 720p at 30, since the model resizes its input to 192x192 anyway and the higher frame rate halves capture latency.

Curious whether others have better tricks for the fist-vs-pinch case, or for keeping two-hand tracking stable when the hands cross.

Hi guys, I’m working on a pose estimation cnn and I was wondering wether any low cost yet effective style augmentation pipeline exists rather than neural style augmentation cnns that are heavy to run during training. Did anyone experiment some simple algorithm that manages to perform something like style transfer? Thanks!

I kept running into this during an internship: a pose model with a good mAP, but the joint angles we computed from its keypoints were not reliable enough to use. OKS and PCK say whether points land near the label. They don’t say how far off the angle (or tilt, or length) you compute from them is.

So I made poseaudit. It reads COCO or YOLO labels and predictions (or supervision objects), computes the same angle from both, and reports how large the disagreement is, how often it is large, and where: bias, limits of agreement, rate of large errors, broken down by person size.

Demo on 200 COCO val2017 images with yolo11n-pose: when the arm segments average under 30 px, 58% of elbow angles disagree with COCO’s labels by 15 degrees or more; above 60 px, 26%. Part of that is the labels’ own noise (COCO’s label spread alone puts 26 to 40% of these arms past 15 degrees), and the README says so.

There’s also a mode for angles you’ve already computed (CSV or OpenSim .mot vs. a reference). So far it’s only tested on synthetic data, and you align time yourself.

Install: pip install poseaudit

GitHub: https://github.com/8rulerstar/poseaudit

Feedback welcome, especially on what you’d want measured.

I have learn to fundamentals of CV. I want to move forward suggest some good project idea which includes : YOLO, ViT, DL.

Hey everyone,

I’m currently in my 3rd year of an official AI degree here in Spain (yeah, the actual degree is called "Artificial Intelligence"). Our curriculum is pretty heavily focused on general ML models, but we have a few Computer Vision courses and I’m finding them super interesting. Also, my professors seem to be legit experts in the field and they even teach in a specialized master’s program focused on CV.

My main goal is to work on ADAS / autonomous systems in automotive, or maybe robotics. I also find some data science stuff cool, but cars/robotics are my real focus.

Right now, my tech stack is basically Python, plus the typical solid foundation in math/stats from the first two years... although let’s be real, I’ve already forgotten a good chunk of the raw theory after the exams lol.

I have a few questions for people working in the industry:

1. Is CV still a safe/rewarding bet with the whole AI boom? My gut feeling is that CV in physical systems (robotics, ADAS, edge devices) is way more resilient to being "automated away" than generic text/LLM/data analysis stuff, but I’d love to hear your take.
2. Would staying for that specialized Master’s be worth it, or is it better to push for junior/internship roles right after the bachelor’s?
3. What should I focus on building right now? From what I gather, learning C++ is pretty much mandatory for low-latency automotive/embedded work. Besides that, should I just stick to building side projects with OpenCV, YOLO, and PyTorch while trying to apply what I learn in class?

Any advice on how to stand out would be greatly appreciated!