​

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?

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

i need to make a person detection in which a video will be uploaded its a fixed footage no moment and it need to detect the persons give them correct id and count them even if they gets blocked and also gets out of frame and comes again teh same id should be used

also i want to count how many people went in and out of that using the virtual line and all

can anyone guide me on which model to choose or what all algorithm to choose

any open source model is enough yolo,rtdetr,cnn or anything

i am new to this and want to do this project so how to do this guys any guidance

I realize, that now once a month someones shares this kind of project, but still wanted to share :)

I wanted to make it work on regular club footage, have it working on 3 courts now. It's mostly general by now, but still requires manual calibration (10 points) on each court, or if camera have moved.

It's my first time dabling with CV, so just playing around. All of it is vibecoded, but with my direction, which is sometimes limited, because.. well, no experience with CV. I have over 10 years of dev experience in other fields, so that helps a lot.

This is an excerpt of my marking/diagnostics app (also vibecoded), two more examples here:

https://streamable.com/au93be
https://streamable.com/axz0pg

All the footage here has gone trough my review (so hits and point endings fixed, don't remember the actual state of these points, but you can see it in the bottom graph (with little square boxes) - the bottom one is the actual label, and the middle one is decoded one. I only now realized, that this might not be in the spirit of this subredit to show "fixed" footage, but it's mostly identical, and I don't have any other examples at the moment)

Some info about the project (AI generated, sorry), if you care about the tech, or want to roast it (please do!):

The pipeline takes a fixed club-camera recording of a padel match and turns it into a list of ball contacts (who hit, when) grouped into points. Every stage feeds the next.

Stages and models:
Court calibration (court_calibrate.py) — no model. A homography plus lens distortion fitted from ~10 clicked court points, so pixel positions can be converted to court metres.

Player tracking (track_players.py) — YOLO detector at 1280 px. Finds the four players each frame and assigns them to court slots (near-left, near-right, far-left, far-right).

Ball detection (track_ball_wasb.py) — WASB, a small heatmap network fine-tuned on padel footage. Run twice: a strict "event" track for kinematics and a looser "state" track only for coverage features.

Player pose (track_pose.py + far-crop pass) — YOLO11-pose, 17 keypoints. Gives wrist/body positions; far players get an upscaled crop pass because they are tiny.

Candidate generation (detect_hits_from_ball.py) — no model. Speed reversals and gaps in the ball track propose possible contact frames and attribute them to a player slot.

Strike head (strike_scores.py, strike_dense.py lattice) — a CNN on player crops around the candidate frame, trained to say "this player is striking now". Scores candidates, re-times them to the true contact frame, and recovers missed hits.

Strike-withhold mask — no model. Suppresses candidates whose attributed player is a stale, frame-clipped box (out of view).

Point decode (decode_points.py) — a Viterbi-style dynamic program over candidates. Uses two gradient-boosted-tree heads: an emission head (is this candidate a real hit) and a bounce head (is this a bounce, not a hit), plus the strike score and ~15 hand-set costs, to pick the hit sequence and open/close points.

Merge stages — join point fragments across short gaps; a small formation MLP vetoes point starts when players are not in a serving formation.

Eval (eval_hits.py) — scores against hand labels with a 6-frame hit tolerance and 12-frame point-start tolerance.

Bottom line: five learned models (WASB ball, YOLO players, YOLO11-pose, strike CNN, two GBT heads + formation MLP) produce evidence; one deterministic decoder turns that evidence into hits and points. Current in-sample pool F1 is 0.9507 across six cameras.

It has around 95% accuracy (detects 95% of hits correctly, within a specific margin). It detects and opens points with around 90% accuracy using serve formation. The problem is the point endings. I realise that it's likely where this project dies - currently I'm using the "quitness" of the ball and the players, and it works decently. But I'm fixing those manually for now, as well as the winners, so I'm able to generate extended report about the match and mistakes.

Other problem I have is long processing time. I already optimized it a bit, but I feel like I'm probobly using to much stuff. The pipeline grown naturally, by using different things to improve the decode. But I feel like I can try to delete some stuff from it. For example, skipping player pose and using strike head only, things like that. Although, I'll want pose for detecting shot types later, so.. yeah..

My current pipeline timings:

Another problem is the ball. Would love to have some suggestions, how I could get the actual 3d position of it, but my research came with nothing valuable for my case (1 camera angle).

Would love to hear any advice, directions or any other feedback. Thank you!

One problem with embodied AI isn't just collecting video; it's turning all that video into usable training data.

Manually annotating every frame doesn't scale particularly well. Automated detection can do much of the initial work, but real-world footage still contains occlusions, partial objects, tracking errors, and boxes that a human may want to correct.

So we wanted to test something practical:
"Can GPU-based automated annotation and human review work together as one complete data-production loop?"

We built a small end-to-end experiment to find out.

I. The workflow

The pipeline was fairly simple:

Raw video → GPU inference → YOLO11n → ByteTrack → MOT annotations → CVAT → human review → reviewed dataset → validation

The idea was to let the GPU handle the repetitive first-pass work while keeping a human in control of the final annotation quality.

II. Running the automated annotation stage

For the GPU stage, we used a instance with an NVIDIA RTX PRO 6000 (96 GB).

The test video was:

• 101.047 seconds

• 3,300 frames

• 1080 × 1920

YOLO11n handled object detection, and ByteTrack maintained object identities across frames.

This produced 12,901 machine-generated annotations across 604 unique tracks 😄

But the numbers aren't particularly interesting until you see the actual output.

This was the machine-generated first pass that we wanted to hand over to a human reviewer.

III. Moving machine annotations into CVAT

The tracking results were converted into MOT-format annotations and imported into CVAT.

The important part here was that CVAT wasn't performing the GPU inference. It was acting as the human-review layer.

The machine-generated detections appeared as editable rectangle tracks over the original video.

This changes the annotation workflow from:

Human labels everything from scratch → Machine generates first pass → human inspects and corrects

For large video datasets, that's the workflow we're interested in exploring further.

IV. We deliberately changed one annotation

We also wanted to verify something that can easily get overlooked:

If a human changes an automatically generated annotation, does that correction actually survive the complete export pipeline?

At frame 2107, we manually adjusted the bounding box around a partially visible person.

We saved the change, exported the reviewed annotations from CVAT, and compared the exported dataset against the original machine-generated annotations.

V. Then we checked whether we could find the change

The results were:

Machine annotations: 12,901
Human-reviewed annotations: 12,901
Matched annotations: 12,901
Unmatched machine: 0
Unmatched reviewed: 0

Average bounding-box IoU across the dataset was:

0.9999556465

And importantly, our independent comparison found the deliberately modified annotation:

Frame: 2107
Class: Person
IoU: 0.791181

That was the result we were really looking for.

The full loop worked:

GPU annotation → CVAT import → human correction → export → independent verification

A quick clarification: the 0.99995 IoU is not a YOLO accuracy score.

We weren't comparing the detections against manually created ground truth. It measures how similar the machine-generated dataset remained after the CVAT round trip. We deliberately changed one annotation to verify that a human correction would survive the process.

Then we asked: what does the GPU part cost?

Once the workflow worked, we ran the same 101.047-second video through the YOLO11n + ByteTrack stage three times:

That gives roughly 2.96× real-time processing for this particular workload.

At the GPUHub instance rate we observed during the experiment, approximately $0.91–$0.96 per compute hour, the average benchmark translates to roughly:

$0.31–$0.32 of GPU compute per hour of source video

The two warm runs were slightly cheaper (~$0.27–$0.28/video-hour), but we're using ~$0.32 as the more conservative preliminary estimate.

This is important: that's GPU inference compute only, not the total cost of producing a reviewed dataset.

It doesn't include human review, CVAT infrastructure, storage, data transfer, QA, or workflow orchestration.

VI. and What did we learn?

The interesting part isn't that an RTX PRO 6000 can run YOLO11n.

What we wanted to validate was the handoff between automation and humans.

We were able to generate structured annotations remotely on a GPU, move those annotations into a separate review environment, edit them manually, export the reviewed dataset, and independently verify that the human correction survived the entire round trip.

So the architecture starts looking like:

Collect → Pre-annotate → Human review → Validate → Training dataset

rather than:

Collect → Manually annotate everything → Training dataset

We haven't measured how much human labor this actually saves yet. That requires a different experiment comparing fully manual annotation against machine pre-annotation + human correction.

That's probably the next benchmark that matters most: reviewer time, final annotation quality, and total cost per reviewed video hour.

For anyone working with robotics, autonomous systems, or large video datasets:

how are you handling the boundary between automated pre-annotation and human review? ✍️

Is this accurate?

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?

I'm stuck between the two fields/topic and can't decide which one to put all my eggs in for masters. A little background, I'm first semester master student doing MS AI from a university in S.Korea. Here in Korea you are expected to join a lab from the start of masters and start preparing for research from the first semester.

I originally planned to join the computer vision lab but due to unforeseen circumstances and me being a little late, I couldn't get in. So, I had no choice but to join another lab.

The main research direction of this lab is emotions and medical ai. But, the the students are working on diverse range of topics from medical (Alzheimer, Xray report, glass slides) to emotions, activity recognition, and there is one student(Phd) doing research in battery AI.

Professor has told me to figure out a direction and read current lab papers. One of my senior (post-doc) recommend the topic of neural decoding, as its a space where there is good opportunity to do meaningful contribution. Since this also fall under medical ai there are people who can guide me.

But my heart is still stuck at 3D Reconstruction+Robotics because I really wants to work in this field. I'm looking to hearing from people how much impact your master research has on your job hunting. If you were in my place how would you think about this. (Also currently no plans fob, r Phd, but can change).

Edit: Next semester computer vision lab might have opening, so If I take 3D Reconstruction/Robotics, there is a chance I can shift (that's a big If tho that I haven't discussed, because I can't talk to the professor without being sure of the topic I want to pursue).

I'm looking for a free vision AI/VLM that can take a screenshot and understand what's on the screen.

My requirements:

Read text from screenshots

Understand UI elements/buttons/windows

Describe what is happening on the screen

Answer questions about the screenshot

Preferably run locally

Python support would be a big plus

I don't need image generation

Smaller/faster model is preferred

What is currently the best free/open-weight vision model for this use case?

Qwen-VL, Gemma, MiniCPM, or something newer?

I'm mainly interested in screen understanding/AI computer automation, not just OCR.

Thanks!

You guys really loved my last sheet music search engine post, so I decided to make a mockup POC of a VLM-powered piano assistant that reads and transcribes notes, procedurally "generates" a visual tutorial, and listens to you play it back. I call it a concept because I still haven't figured out a way to actually generate a 3D animation on the fly. My best option was Concert Creator, but that was shut down over 4 years ago RIP. So for the time being, I'm having to pre-make the animations.

On the more technical side, Qwen 3.6 27B is taking both video stream and natural language as input, and uses that to determine what smaller task-specific models to call on for the situation. In this case, it's using segmentation, homography, pitch detection, and a custom music OCR model (open source called cadenCV). In short, the VLM is acting as an orchestrator that can see things and reason the best course of action because I'm too much of a lazy bum to hard-code a set of rules for when each model gets called on.

The next step is to figure out how to make it run in real time.

I found a massive dataset of dummy hard CAPTCHAs on Kaggle and ran them through Qwen 3.6 and other models. Results are not too shabby, it was damn near on the money for a lot of the images. I'm confident Qwen 3.8 would pass a lot of these.

Hello everyone -

I wanted to know your thoughts and also recommendations of improvements on this please. I built this knife skill assessment for chopping vegetables this summer after reading several papers on cooking as a science. The goal was to find the hardest skill that required a common tool (knife) and then score it. The reason I did this was because I'd like cooks to be paid for their invisible labor and not just hourly as I know how hard that job is. But I doubt this would be beneficial lol ... Anyways, I am more than willing to go into details about what I used starting with the programming language (c++) and temporal and spatial models including how kalman filters were used here. The link to it is down below:

https://cookcredit-knife-demo.web.app/

This is a follow-up to my previous post on synthetic-to-real keypoint detection and 6D pose estimation.

This time I ran the same pipeline on two very different platforms:

Object detection → crop → keypoint detection → PnP

Ubuntu + CUDA (RTX 2000 Ada)

• Detection: 60.25 ms
• Keypoint: 21.87 ms
• PnP: 5.18 ms
• Total: 87.71 ms (11.60 FPS)

Raspberry Pi 5 (CPU)

• Detection: 70.36 ms
• Keypoint: 56.06 ms
• PnP: 5.34 ms
• Total: 132.12 ms (7.60 FPS)

The video shows the outputs side by side on the same 569 real-world frames.

What surprised me was that the Raspberry Pi 5 was not dramatically slower. The largest difference was in keypoint inference, while PnP was essentially the same.

The outputs were also practically identical. I found occasional frames where the final PnP pose differed slightly between the two platforms, likely due to small numerical differences propagating through PnP/RANSAC, but I did not observe a consistent accuracy advantage on either platform.

For this experiment, I would consider the two platforms effectively equivalent in accuracy, with the main difference being inference speed.

I'm also preparing a technical write-up and plan to publish the implementation on GitHub.

Hello all,

I'm a radar signal processing engineer and i trained a 5-class classifier (car, large_vehicle, two_wheeler, pedestrian, pedestrian_group) on RadarScenes radar point clouds.

The input vector is a per-scan histogram (16 bins) and the network is a 3-layer MLP. The loss function is a class-weighted cross-entropy loss. This work is based on "Histogram-based Deep Learning for Automotive Radar" paper.

I scoped the project to be one scan only. Accumulation of multiple scans is the next step.

Data

Class Imbalance: two-wheelers and large_vehicles has a low number of occurences.

Aggregated Classes: two_wheeler mixes bicycles and motorized variants; large_vehicle merges trucks, buses, and trains together due to data scarcity.

Sequence Bias: Long tracks of slow-moving objects can skew a particular data split velocity distribution, causing high F1 score variance across folds.

Ablation studies

I tried with bigger MLPs, alternative feature encodings, and different histogram binning, all moved performance less than the variation caused by changing the train/validation/test split. I measured that split sensitivity across 6 folds, keeping the same proportions.

Changing the histogram to per-instance statistics (mean/median/std) slightly degraded performance.

Main findings

Macro F1 rises from 0.381 to 0.764 as the naturally occurring number of radar detections per instance increases from 1 to 5. I trained the model normally using all available detections, then bucketed its existing validation predictions by each instance's detection count and computed macro F1 per bucket.

The classes car and pedestrian has the best performance and two_wheeler has the worst.

A car is often confused as large vehicle when the car was wider than usual or had a unusually high rcs (which can happen due to multipath for example).

The two_wheeler is often confused as pedestrian because their vr_compensated distributions overlap, which is the the model's single most important feature for these two classes. A stationary or idling two_wheeler is indistinguishable from a pedestrian.

I uploaded an image with ground truth vs predictions: A nearly stationary two-wheeler which contains a single point was predicted as pedestrian, because its velocity is near zero, indistinguishable from a pedestrian. A car in the same scene, also with just one point, is classified correctly, since RCS and Doppler are enough for that class.

Full writeup here: https://github.com/brunopinto900/radar-ml-autonomous-driving/blob/main/MLP_Report.md

Future work

Implement other spatial encoding schemas (point net for example) and accumulate multiple scans to tackle the challenge of sparsity and explore the concept of micro-doppler.

Qwen 3.6 27B watches the scene and acts as an orchestrator, prompting smaller task-specific models to perform OCR, segmentation, and edge detection. The segmented notes then get matched to real pieces using "A Dictionary of Musical Themes" database via Themefinder. I’m sure there are already many sheet music search engines out there, but I built this more as an experiment to see how I can turn VLMs into full-on vision agents. 

Disclaimer: footage is sped up, this is not real-time.

Hand pose is fine on an open hand in free space. Soon as the hand actually grabs something, half the keypoints disappear behind the object and predictions start drifting.

What do people actually do here? Temporal smoothing across frames to fill the occluded joints, or train on data with occluded joints properly labelled? Second one seems more correct but way harder to get, since annotating a joint nobody can see means either guessing or multi view capture.

Also not sure how much the object should be in the model. Predicting hand and object together should help, contact points constrain the pose. But I've seen people say it just overfits to whatever objects were in training.

Anyone got a setup that holds up on real grasping footage?

DISCLAIMER: I am very new to computer vision, I started reading about it a week ago, so please bear with me. 😊

Hi, I am exploring a way to sync action cam footage with GPS recordings and I came to you smart people for an advice!

Goal

Estimate relative speed vs time curve from action cam footage of different sport activities (i.e. should not rely on features such as road)

What I am trying to achieve

I am trying to sync video footage with GPS recordings. However, when video metadata is absent automatic syncing (based on timestamps) fails and manual syncing is a real pain. I started to experiment with computer vision to derive turning-rates/speed changes and match them with GPS to find the sync offset. The video shows the typical footage to be analyzed (minus the telemetry).

What I have done so far

I managed to implement some primitive (and likely very bad) turning-rate tracking. I use OpenCV sparse feature tracking with pyramidal Lucas–Kanade, then fit estimateAffinePartial2D with RANSAC to the tracked points. I use the resulting global horizontal/rotational image motion as the video-side turning signal and compare it against heading-rate from the activity data. I managed to get ok correlations (0.6-0.75) and could reliably identify sync offsets for a series of 5 test videos (as short as 4 min footage within 5 hour activity).

The struggles of speed

I thought cross-correlation with speed would improve reliability. I tried different ways of deriving the speed but always ended up with just super spiky mess with no information at all. One of the problems I understand is that the perception of speed (optical flow) is different e.g. in a forest and on open field. The only thing I managed to get to work somehow was incremental sfm using visloc-rs, but it was extremely slow no matter how I tried to optimize it (few mins per 1 min of footage). The speed-tracking solutions I found either track vehicles from 3rd person view, or rely on specific features like road (and markings).

The question

I do not need absolute speed or even a perfectly smooth estimate. I only need a relative speed-vs-time signal whose changes roughly follow the real speed well enough for cross-correlation with GPS.

Given that constraint, what CV approach would you use to estimate such a signal from a general action-cam footage?

This was my first attempt, and I am very happy with how it turned out.

Hi everyone,
I'm designing a system to monitor the fill level (%) of fertilizer boxes in real-time. I'd love some
hardware and architecture advice from those who have deployed CV in industrial settings.

The Problem:
Need to calculate the % full of a box continuously. The environment is industrial, meaning variable lighting and potentially a lot of fertilizer dust.

I'm a master's student. My thesis is on self-supervised denoising of real sRGB images, and my graduation requirement is a journal paper whose results beat the current state of the art - TM-BSN (triangular-masked blind-spot network + U-Net distillation, ~38.18 dB on SIDD).

My current plan:

1. Reproduce TM-BSN's reported results (in progress)

2. Attack its weak points: the fixed diamond mask (make it learnable / camera-adaptive), the distillation stage (stronger student, better pseudo-labels), and the training recipe (EMA, losses, schedule)

I'm looking for someone with experience in low-level vision / blind-spot networks (AP-BSN, TBSN, etc.) interested in collaborating: discussing ideas, reviewing experiment design, challenging my results. I'll do the implementation and training myself; substantial contributions would earn co-authorship on the paper.

DM me or comment if interested.

I just released Birder 0.8.0, with a bunch of updates around MoE ViTs and NaFlex training.

The main addition is DeepSeek-v3-style MoE layers for ViTs.

Alongside shared experts, I also added optional special-token experts for CLS and REG tokens. I’m not yet sure how useful these will be in practice, but they seemed interesting enough to experiment with.

There’s also support for Expert Choice routing, in addition to V-MoE-style routing.

From some initial runs, this setup seems to be working better for me than V-MoE, although the experiments are still fairly small. Once I’ve done a more substantial training run, I’m planning to write up a more technical post about the implementation and results.

MoE training using either bias-update routing or an auxiliary load-balancing loss is now supported pretty much across the board in Birder.

---

I also released a NaFlex ViT pretrained with NEPA.

The model was trained with:

• variable patch sizes from 14 to 32
• input resolutions from 192 to 320
• sequence lengths from 36 to 400
• roughly 20M training images

The training mixture included datasets such as ImageNet-22K, GLDv2 and Places365.

Model: https://huggingface.co/birder-project/naflex_vit_b16_nepa-generic

---

I’m currently working on making DINOv2 / Franca NaFlex-friendly as well.

The NaFlex implementation was heavily influenced by Ross Wightman’s work on OpenCLIP NaFlex, which was very helpful.

---

Still early on some of the MoE experiments, so I’d be especially interested in feedback from anyone who has worked with MoE routing in ViTs, Expert Choice, or variable patch-size training.

I kept running into the same annoying workflow when working on computer vision projects:

A dataset/download works perfectly in Chrome because I'm already authenticated, but I actually need the files on a remote GPU server or HPC cluster.

Copying the URL usually isn't enough because the browser request may also depend on cookies, authorization headers, Referer, POST data, etc.

So I built dl2curl, a small open-source Chrome extension.

You start the download normally and it reconstructs the request as a ready-to-paste:

• curl
• wget
• aria2c

command.

My workflow is basically:

dataset website → Chrome download → copy command → SSH → remote GPU server

aria2c is especially useful for large dataset downloads.

Everything is processed locally. There is no backend or analytics, and the project is fully open source.

Chrome Web Store:
https://chromewebstore.google.com/detail/dl2curl/acglnggnojeejnchepliijapneiaffpe

GitHub:
https://github.com/ardaerendogru/dl2curl

I originally made it for my own research workflow, so I'd be interested in feedback from people downloading datasets/checkpoints to remote training machines — especially if you know sites with unusual authentication/download flows that might break it.

Hi Team, right now my project involves a black box wherein I input a PDF that contains students' handwritten answer sheets.
output is structured JSON that also contains bounding boxes of the students' answers (Coarse answer boxes roughly covering the student's answer)

Right now, the LLM is doing this and doing pretty well -- are there any cheaper alternatives?

Context- So as a part of a build week project I decided to build a Ironing dataset on hugging face to measure the slips and anchors for textile manipulation. Eventually to be used for simulation/robot experiments.

Since its a small pilot set I've done most of this at home with constraints and a regular top down video angle.

Help: I wanted feedback on my data quality. What did I miss ?!

Dataset:

https://huggingface.co/datasets/CaramelCoffee19/naive-physics-ironing-v0.2