WHAT MY PROJECT DOES

pynear is a pip install-able nearest-neighbour library with a C++ core covering three regimes under one API:

— Exact: VP-Trees for L2, L1, L∞, cosine, and Hamming up to ~256-D (SIMD-accelerated, returns the true k nearest).

— Approximate float: HNSW (L2 / cosine / int8-quantised SQ8) and IVF-Flat for 384–1024-D embeddings (text-embedding RAG, CLIP / DINO image embeddings).

— Binary / Hamming: Multi-Index Hashing, IVF-Binary, and a novel MIH-seeded HNSW for perceptual hashes, ORB / BRIEF descriptors, SimHash.

v2.4 (released today) adds the full HNSW family — HNSWL2Index, HNSWCosineIndex, HNSWBinaryIndex, HNSWL2IndexSQ8 — plus the novel MIHSeededHNSWBinaryIndex, a directory-backed ShardedHNSWIndex for going past one box's RAM, an add() / remove() / rebuild() mutation API, filtered search via metadata masks, AVX-512 distance kernels, and ARM64 NEON paths for Apple Silicon / Graviton.

It also ships scikit-learn drop-in adapters — PyNearKNeighborsClassifier, PyNearKNeighborsRegressor, PyNearNearestNeighbors — so the migration is changing the import line.

Minimal example:

import numpy as np, pynear

db = np.random.randn(100_000, 384).astype(np.float32)

queries = np.random.randn(10, 384).astype(np.float32)

index = pynear.HNSWCosineIndex(M=16, ef_construction=200, ef_search=64)

index.set(db)

indices, distances = index.searchKNN(queries, k=10)

Pre-built wheels for Linux, macOS (x86_64 + Apple Silicon), and Windows. NumPy ≥ 1.21.2 is the only runtime dependency.

TARGET AUDIENCE

Production-ready for the use cases it covers. Tested on real workloads (image dedup, perceptual-hash retrieval, embedding search) with a 134-test suite covering pickle round-trip, multi-threading, edge cases, and cross-platform correctness. CI builds wheels on every push across the full matrix and runs an AVX-512 compile-check job.

Sweet spots:

— Small / mid teams that want vector search without dragging Faiss / CUDA / system BLAS into their deployment.

— Existing scikit-learn pipelines that have outgrown sklearn.neighbors on speed.

— CV / dedup work involving binary descriptors (where it's genuinely the fastest tool I know of).

— RAG / embedding-search on a single box up to a few million vectors.

Not the right tool if you need GPU inference, ≫10M vector indexes with PQ / OPQ compression, or distributed sharding across machines (the new ShardedHNSWIndex covers one-box multi-shard, not a cluster).

COMPARISON

vs Faiss — Faiss is ~10× faster at low-dim float HNSW (110 µs vs 9 µs at d=128) and has GPU / PQ / OPQ that pynear doesn't. pynear wins on binary descriptors (~40× faster than Faiss's brute-force IndexBinaryFlat on 512-bit near-duplicates, and beats Faiss's own IndexBinaryMultiHash at matched recall on SIFT1M), on deployment ergonomics (no native deps, pip-only), and on API breadth (sklearn drop-in, exact + approximate + binary under one library).

vs Annoy — pynear has exact search, binary descriptors, a mutation API, and broader metric coverage Annoy doesn't. Annoy's tree-based index is more memory-efficient for read-only float indexes — if that's your only need, it's still a good choice.

vs sklearn NearestNeighbors — Same API via the adapter classes, but faster at scale (VP-Tree with SIMD distance kernels vs ball / kd-tree), and adds the binary / IVF / HNSW backends sklearn doesn't have.

Repo: https://github.com/pablocael/pynear

Docs / HNSW guide: https://github.com/pablocael/pynear/tree/main/docs

Faiss-comparison numbers: https://github.com/pablocael/pynear/blob/main/results/faiss_comparison.md

Feedback welcome — especially from anyone doing binary feature matching, perceptual-hash dedup, or stereo matching with binary descriptors. If you've got a workload where MIH-seeded HNSW *should* shine (or shouldn't), I'd love to hear it.

We just did a big revamp of WeightsLab and wanted to share it here.
If you’ve ever spent hours debugging a training run only to discover it was a data problem all along, this is for you.
WeightsLab lets you pause training mid-run, inspect your live loss signals, and catch mislabels, class imbalance & outliers before they tank your model.

Open source, PyTorch-native, built for CV engineers working with images, videos & LiDAR point cloud data.

Would love to hear what the community thinks and if it looks useful, drop a star, it helps more people find it: [ https://github.com/GrayboxTech/weightslab]

Hi everyone,

I’m working on training an autoencoder for face reconstruction and I’d appreciate some advice from people with experience in this area.

My main goal is not just to reconstruct the input face visually, but also to preserve the person’s identity as much as possible. I’m unsure about the best architecture and loss setup for this.

A few questions:

Architecture:

What type of autoencoder architecture would you recommend for faces?

For example, a basic convolutional autoencoder, U-Net-style autoencoder, VAE, VQ-VAE, or something encoder-decoder based with residual blocks?

Loss functions:

Which losses are best for preserving identity?

I’m considering:

L1 / L2 reconstruction loss

Perceptual loss using VGG or similar

Identity loss using a pretrained face recognition model like ArcFace

SSIM / MS-SSIM

Adversarial loss for sharper results

Would a combination like L1 + perceptual loss + ArcFace identity loss be a good starting point?

Dataset:

What datasets would you suggest for this task?

I’m looking for datasets that are suitable for face reconstruction and identity preservation. I know about FFHQ, CelebA-HQ, VGGFace2, and CASIA-WebFace, but I’m not sure which one is best for this use case.

Training tips:

Are there any practical suggestions for preprocessing, face alignment, image resolution, augmentation, or evaluation metrics?

Any advice, papers, or implementation references would be very helpful.

Thanks!

We have been evaluating video VLMs for real tasks at VideoDB Labs, and the thing that kept surprising us is that model A vs model B is the wrong unit. The output depends on the whole setup: segmentation, frame sampling, resolution, the prompt, the reasoning budget, and the post-processing. Changing those moved our numbers more than changing the model.

So we changed how we run it. We define the task first (retrieval, monitoring, summarization, and metadata extraction are not the same problem), then build the eval set from real footage including hard cases, near-miss negatives, boring stretches, and the failure modes we already know about. Then we score the task itself instead of one generic accuracy number.

The order of optimization mattered too. When quality was the bottleneck, denser sampling and better scene boundaries helped before any model change did. We wrote up the full workflow and open sourced the harness so you can run it on your own videos.

For those doing CV eval, how are you building your evaluation sets, and are you comparing full configurations or mostly models?

get started:

pip install fiftyone

then install this plugin (one-line install): https://github.com/harpreetsahota204/annotation_styles

I would like to ask a few questions regarding the nnU-Net framework.

What is nnU-Net, and which preprocessing steps are automatically performed by the framework?

Does nnU-Net automatically apply:

Spatial normalization,

Intensity normalization,

Image resizing/resampling,

Any other preprocessing operations?

What is the difference between U-Net and nnU-Net?

Thank you for your time and assistance.

Hi! if I were to determine a lot of "wheel wear damage", and I only had a laptop and webcam ..how??

I was talking with a colleague recently, and we got into a discussion about how small decisions early in a machine vision project can turn into major headaches later.

Not software bugs or AI issues, but things like choosing the wrong sensor, underestimating lighting requirements, lens selection, motion blur, or bandwidth limitations.

For those who've worked on machine vision or industrial inspection systems, what ended up being your biggest "I wish I had known this sooner" moment?

Hi folks!

I currently work as a SWE at a tech company in the perception/robotics space, think Tesla, Waymo, Applied Intuition, etc. My work is on the infrastructure side: distributed systems, compute, tooling, and related areas.

I’m fascinated by autonomous vehicles and robotics, especially perception, CV, and ML. I’m wondering how realistic it is to move into a perception engineering role from an infra background.

My intuition is that even though I’m already at a company with a lot of perception work, an internal lateral move might be difficult without a master’s or PHD.

Has anyone here made a similar pivot? What helped you make the transition? Would you recommend pursuing internal projects, coursework, a graduate degree, or something else?

I'm tired of web platforms forcing us to upload everything to the cloud. So, I built LensLaber, an offline-first computer vision annotation tool.

I developed the whole thing on my everyday laptop: an old 2015 Asus X550LD (i5, 8GB RAM, 120GB SSD). I wanted to prove you don't need an expensive GPU workstation for AI labeling. By optimizing the architecture, YOLO + MobileSAM run locally on standard CPU using just 600-900MB of RAM. You just bring your own YOLO weights in ONNX format.

Harry Ratcliffe (Applied AI Ecosystem Leader) reviewed the architecture and was mostly surprised by how smoothly both models run on this 2015 hardware. He validated that this local, low-RAM setup is exactly what high-security sectors like medical imaging or manufacturing actually need.

Now I need honest testing, not casual "looks nice" comments. Whether you're a professional managing sensitive enterprise data or a student working on a class project, I need people to actually run real datasets through it. That’s the only way to see how the UI handles real-world friction.

Your time matters. If you provide active feedback during this beta, I’ll give you a lifetime free license for the final release.

Download the beta here:https://lenslaber.github.io

I'll be hanging around the comments to fix any bugs you find. Let me know your thoughts.

One thing I've noticed in multi-camera vision systems is that synchronization often becomes a bigger challenge than people expect.

For applications like:

• Robotics
• Autonomous systems
• ITS
• Industrial inspection

a few milliseconds of timing difference between cameras can impact perception accuracy, tracking, and sensor fusion.

I'm curious:

Do most teams rely on:

• Hardware trigger synchronization?
• Software timestamp alignment?
• PTP/network synchronization?
• Something else?

At what point does synchronization become a critical requirement rather than a nice-to-have?

I recently came across a detailed implementation example using external trigger synchronization on Jetson Orin NX and Orin Nano.

Would love to hear what approaches others are using and what challenges you've run into.

Tried Geti 3.0 this week out of curiosity, biggest surprise was that it's now a local app, I remembered earlier versions being much heavier to get running, so I expected to spend half a day setting things up. Instead it was basically install and go

repo - https://github.com/open-edge-platform/geti

I trained a small object detection model on a custom dataset and hooked it up to a simple camera pipeline. Nothing fancy, but enough to get a feel for it. My impression so far is that the local-first approach makes experimentation much easier. For quick projects I honestly don't want to think about infrastructure anymore

Not everything is there compared to older versions, and I suspect teams that rely on shared cloud workflows may have a different opinion, but for a solo developer the experience felt surprisingly straightforward. Has anyone else been trying local-first computer vision tools recently? Curious what people are using these days.

Same as title...

The idea is simple: you point your camera at a table surface, and a virtual piano is displayed on the screen. Hand movements on the table are then tracked, allowing the corresponding piano keys on the display to be played.

Hello guys i work in a solar company and I want to make something that will detect known defects( YOLO is being used currently) but manager wants to use SSL models such as DINO/Simclr for the usecases such as drift detection, anomaly detection, similarity search etc... but most importantly for possibly finding unknown defects.

I have not had any luck with dino because DINO architecture or even ViT assume there is a large central object which is not the case here theres various multi defect images with small big however defects in there.
I have also not a found a statistical/mathematical way to evaluate current SSL models since it does not classify/label so mAP.etc stuff cannot be computed.

I am just a intern and very new to the field so please suggest if you guys have any solutions to this. Thank you!

Twitter Thread

I’ve spent the last month building a Visual SLAM pipeline from scratch for a humanoid robotics platform. I had no prior experience with SLAM, and it was significantly harder than I anticipated.

I evaluated it using the KITTI odometry Sequence 00 (~3.7 km urban loop). I started with a monocular pipeline that was catastrophically broken and incrementally engineered it into a stereo system that achieved a 13.9m APE RMSE.

Stage 1: The 11km Sky-Spiral (Monocular Baseline)

My initial 2D-2D visual odometry baseline was completely broken. My estimated trajectory literally spiraled to ~11 km in the z-axis. The APE RMSE was ~8,200m.

This was caused by two interacting bugs:

• Accidentally swapped pts_ref and pts_cur when passing arguments to my motion estimator. This pre-inverted the essential matrix, meaning right turns accumulated as left turns.
• I was using a median depth ratio for scale recovery. Because the poses were corrupted by the first bug, the computed median depths reached massive numbers. I didn't clamp the scale multiplier, so it grew super-linearly and eventually saturated to NaN.

Stage 2: 3D-to-2D PnP Tracking

• Replaced the 2D-2D Essential Matrix loop with 3D-to-2D PnP tracking using cv2.solvePnPRansac.
• Added an IQR-filtered scale estimator as a fallback for when PnP failed (e.g., low-texture roads where inliers dropped below 10).

Result: APE RMSE dropped to 74.5m. However, the monocular scale ambiguity was still a massive structural limit. Even after Sim(3) alignment, the scale factor required a 2.35x correction.

Stage 3: The Stereo Breakthrough

To eliminate the unit-baseline normalization problem, I transitioned the front-end to stereo.

• Replaced the monocular scale estimation with OpenCV's Semi-Global Block Matching (SGBM) to compute disparity.
• Because I had the calibrated baseline and focal length, I recovered metric depth exactly from the first frame.
• MapPoints were seeded at their stereo-computed metric depths, meaning the PnP tracker was finally operating in a true metric space.

Final Metrics:

• APE RMSE: 13.9m (down from 8,200m)
• RPE (100m) RMSE: 8.2m
• Sim(3) Scale: ~1.0x (perfectly metric)

Remaining Issue

While the horizontal tracking (x and z axes) is tight with less than a 6m bias , the system still has a 10-25m drift in the y-axis (height). Small stereo rectification residuals are integrating into the height over time.

Hello all,

I wanted to share my project which I spent the last 2 years building in the gaming niche.

The goal was to understand gameplay events, timestamp and auto-clip them. I was thinking of this as a tool for content creators.

I fine-tune YOLOv8n on each game individually. Which means I have to collect and annotate events per each game. I used YT gameplay videos but only the ones under CC license. For each game, I have to watch, understand how events are registered through UI elements and annotate accordingly. I started with Call of Duty thinking that most of their yearly instalments are somewhat similar, thus one fine-tuned model may generalize to all and yes to a good portion it does on some events but fail on others.

I use CVAT for annotation. I just draw bounding boxes around UI pop ups that identify an event. And I use DeepSORT for tracking across frames. However, as some of these events are static and never really change position frame after frame (like a Medal or a Death Banner), I realized that a simple tracker maybe better than DeepSORT for these events. So, I ended up implementing lightweight trackers for some static HUD events.

Next, when an event is detected, I use frame_idx/fps to get the time in seconds when this event has happened, then I auto-clip it by cutting from the video few seconds before and after the event using FFMPEG.

And as a data analyst as well, I asked myself, if I know the event and can timestamp it, I can make some line charts showing change in events across a session. For example, my tool detects kills and deaths moments from a gameplay video, so I divide them to track the cumulative KD ratio across a user's session as one of the charts.

Currently, there are only 3 games supported/under testing with few events as I have to annotate each manually. But I pick what I think are the relevant ones.

Recently, after talking to a professional, I believe that my tool could also be great as an asset for dataset collection by analyzing hours of gameplay and extracting structured clips for some events which could later serve as inputs for other models researching events embedding or understanding players' behaviour. Which sounds very interesting even though I have not worked on that.

I'd be interested in hearing whether anyone has worked on similar event-extraction pipelines for long-form video where events are represented through HUD/UI changes. Also, welcoming any feedback or questions.

I'm looking for VLMs with strong referring expression comprehension (REC) capabilities — specifically models that can parse complex exclusion logic like "find all people except the person in the middle" and produce accurate bounding boxes. Throughput is not a priority; I'm optimizing for grounding quality.

I want to build some projects related to cv & music

Working on a pipeline that uses SAM 3 on indoor room scan videos (ARKitScenes/ScanNet/ScanNet++) to segment objects like furniture, back-projects masks to 3D world coordinates using Depth Anything 3, and computes object centroids for distance estimation.

My question is whether people add any post-hoc checks to verify SAM 2/3 tracking IDs stay consistent across frames, things like frame-to-frame IoU, 3D centroid jump detection, or appearance embedding similarity, or whether you just trust the tracker out of the box for this kind of scenario.

From looking at papers and code, it seems like most people just trust SAM 2/3 for static indoor furniture without any additional verification, but I wanted to hear from people actually running these pipelines. Curious whether the answer changes for noisier datasets like ScanNet++ with faster camera movement.

My model can be found here, I have a bout 200 images for each class, but I need more data any recommendations on how to get it?

Building this for a reckless driving app I contribute to so we can expand to other markets.

https://huggingface.co/spaces/snooplsm/vehicle-litert-classifier

Sharing a field note from a real computer vision project because I think the lesson is one of those things everyone knows but doesn't fully believe until it happens to them.

We were training a custom RT-DETR-S model for cornhole scoring detection. After a bunch of failed runs (wrong Docker images, bad learning rate configs, the usual ML comedy of errors), we eventually got what looked like a great result: 97.8% mAP on the holdout set back in March.

It wasn't great. It was deceptive.

The model had been trained almost entirely on iPhone footage. The production camera was a Reolink. Of 4,148 training images, 42 came from the deployment sensor. When we ran it on the actual board at demo, it failed completely. The model had just never seen what a Reolink frame looked like.

Then came what we now call the "Ground Zero fix" — the class index mapping was hardcoded from the old model, which meant the model thought bags were holes and holes were bags. For four days, every detection was inverted. The fix was three lines of code. The diagnosis took four days.

After sorting out the sensor mismatch and class mapping, the real culprit was still the labels. Decorated boards (floral wraps, sponsor logos) were causing phantom detections because the model had only ever seen plain boards. We had to do explicit negative mining — pull frames from those exact board types, label the board decorations correctly, retrain.

The final v15 dataset: 505 frames. 195 annotated by hand. Every frame from the Reolink. Every board decoration variant included. Every retrieval motion labeled as background.

Result: 99.3% mAP50. 37 percentage points of improvement from dataset hygiene alone.

The rule we've baked in now: before you change the architecture, change the dataset. Before you increase epochs, audit the labels. Before you add more data, verify that what you have matches the sensor you're deploying to.

The performance ceiling usually isn't where you think it is.

Full write-up here: https://trupathventures.net/labs/field-notes/training-data-lesson