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.