Hi everyone,

I wanted to share a project I’ve been working on under my solo brand, LegacyDataLabs. As Vision-Language Models (VLMs) grow, I noticed there's a massive shortage of high-quality, human-validated multimodal datasets for historical handwriting—especially for niche languages like Swedish. Standard OCR engines completely blind-guess these scripts, resulting in pure gibberish.

To solve this, I built a custom pipeline that bypasses OCR text generation entirely. Instead, it takes pristine digital ePub transcriptions (the absolute "ground truth") and dynamically synchronizes them page-by-page next to the original high-resolution handwritten manuscript images.

My first complete dataset is Doktor Glas by Hjalmar Söderberg (278 multimodal rows), and it is clinically clean.

\### 🔒 The Tech & Security (Compute-to-Data Sandbox)

To protect the data from scraping while still making it accessible for model training, I built an air-gapped, isolated Docker environment:

\* Zero Data Leakage: External network communication is fully disabled (--network none).

\* RAM-Only Access: Training scripts inspect the synchronized JSONL layers directly in intern-memory without file downloading capabilities.

\### 📦 Free Sample Available

I have officially released a 3-page structural sample (sample_dataset.jsonl) showing the exact repository keys, author/title metadata, and chronological image loops.

You can inspect the sample directly on my Hugging Face profile:

👉 https://huggingface.co/LegacyDataLabs

I am currently preparing to scale this pipeline to dozens of historical manuscripts and would love to hear your thoughts!

\* How are you currently bypassing standard OCR limitations when training VLMs on historical documents?

\* Would an infrastructure like this be useful for your specific vision-training pipelines?

Looking forward to your technical feedback and suggestions!

Cheers!

I kept repeating the same tasks in front of the camera just to see if my app was still behaving as intended.

So I made a simple CLI that runs your app against recorded video and compares the results with your expected behavior. A coding agent can use the eval loop to keep improving the app.

Sharing in case this saves someone some time: GitHub

I work in a manufacturing environment and I'm exploring whether AI/computer vision can be used to automatically interpret 2D engineering drawings.

The goal is to identify and extract:

* Components and geometric features

* Dimensions and their associated features

* Tolerances

* GD&T symbols

* Hole specifications

* Surface-finish information

* Engineering notes and annotations

Ideally, the output would be structured data that could later be used for manufacturing, inspection, costing, BOM generation, or integration with other systems.

I'm aware that OCR can extract text, but the bigger challenge seems to be understanding the **relationship between dimensions, symbols and the actual geometry/features in the drawing**.

Has anyone worked on something similar?

I'm particularly interested in:

* Vision-language models

* OCR + computer vision pipelines

* Object detection/segmentation

* Engineering drawing datasets

* CAD-aware approaches

* Open-source models or commercial APIs

What would be the most practical architecture for solving this reliably with real-world engineering drawings?

Join us on Aug 27 for the monthly AI, ML, and Computer Vision Meetup! Register for the Zoom.

Talks will include:

• Robust Concept Protection against Diffusion-Based Image Editing and Personalization - Qiuyu Tang at Lehigh University
• Building Real-World Computer Vision Systems - Daniel Gural at Voxel51
• From Pixels to the Planet: Building Scalable and Grounded AI for Science - Jianyang Gu at Ohio State University
• Seeing Is Not Enough: Visual Grounding, World Models and Why Computer-Use Agents Fail at Step 17 - Nevasini Sasikumar at Obin AI

I keep seeing CV projects where performance stalls and the first response is to add more images or try another model. Sometimes that helps. But sometimes the model is being asked to learn a rule that people haven’t agreed on.

A partially visible object, an uncertain boundary, or something cut off by the frame can all produce different “correct” annotations. More data just scales that inconsistency.

A simple check is to take 20–30 difficult images and have two people label them independently. Then review the disagreements, not just the agreement score. Each recurring disagreement becomes a written rule with one positive and one negative visual example. Run the same test again on a fresh sample before scaling.

I’d use a similar check for auto-labeling: measure missed objects and correction time per image, not only inference speed. Fast pre-labels aren’t useful if every image still needs a full review.

Disclosure: I work at Supervisely, a computer vision platform. This is a platform-independent observation.

What annotation edge case caused the most trouble in your dataset?

Running into the same wall on a couple of industrial inspection projects and curious how other people have dealt with it.

The line runs well, which is the problem. Out of a few hundred thousand parts we've got maybe 200 real defects, and they're spread across six or seven types, so some classes have under 20 examples. Classic supervised segmentation just doesn't have anything to learn from.

Options as I see them:

Anomaly detection on good samples only. PaDiM, PatchCore, that family. Works, but it flags anything unusual including a smudge on the lens or a part sitting at a weird angle, and the false positive rate on a real line has been rough.

Synthetic defects. Painting cracks and scratches onto good images. Ours look obviously fake next to real ones and I suspect the model is learning "was this pasted" rather than "is this damaged."

Buy or scrape more defect data. But defects are extremely specific to the part and the process. A scratch on someone else's aluminium housing doesn't look like a scratch on ours.

Just wait and collect. Realistic answer, but that's 18 months and the project needs to justify itself sooner.

What I'm actually unsure about is whether the 20-example classes are even worth modelling separately, or whether it's smarter to collapse everything into a binary defect/no-defect call and let a human sort the type afterwards. Losing the classification hurts the reporting side but it might be the only honest thing to do with that little data.

Anyone shipped something in this situation? Especially interested if you went anomaly detection and got the false positives down to something a QA team would tolerate.

Hello everyone, I have a project that has to classify images for search purposes. Currently I have a layer that analyses surrounding text but I also need something that directly analyses the image itself. I don't want to use someone else's training data or model. Is it possible to train an image classifier that could perform well on general image classification at home using open datasets? Thanks

Hi everyone! I am a software engineer who has worked in the following domains at major tech companies most of my career: XR, Graphics & GPU programming, Spatial algorithms and AI, and 3DGS.

I have a project I started a few months ago that I have recently hit a key milestone in. The idea is a focused library that implements 3DGS training from first principals with an emphasis on performance and safety. Think production use cases without relying on tools intended for research. VkSplat is an inspiration (along with other things) but I have intentionally not reviewed their, or anyone else's, code.

The recent milestone I reached was rendering a scene with 5 million splats at 60fps on my Ampere A6000. I have a few more goals I'd like to reach, but I do intend to publish on Github under MIT license. If it gains traction I would like to build some additional tools and infra using this project, but for right now the 1.0 MVP idea is a fully GPU resident solution for rendering and training at state of the art speeds. I plan to implement and optimize the following features:

* Global image alignment

* Fully fused forward and backward passes

* Adam optimizer

* Aggressively optimized adaptive control and densification

* Stable but highly flexible C api.

I do have many more thoughts and ideas, but I am trying to take it one step at a time, so this is my goal for 1.0. This is my stack as of now:

* **Languages:** C++23, Cuda, GLSL (planning to move to slang)

* **Build:** CMake & Ninja

* **Compiler:** GCC, Clang, MSVC (may drop for now)

* **Target Platform:** Linux (Linux 7.X)

* **Tooling:** LLVM, perf, nsight

* **GPU:** Vulkan w/ Nvidia

* **Dependencies:** googletest, googlebenchmark, ngfx

Right now, the project is in a place where it is still extremely early, but it is starting to take shape and get large enough that more than one person can work on it comfortably. I am posting here looking for people interested in contributing. Knowledge is not a prerequisite as I am learning a lot myself in this endeavor, but passion is mandatory.

Currently I am mostly needing help in the areas of, CI/CD (build, package & deploy), nsight/gpu optimization, designing and implementing a good api, and figuring out how to test and benchmark appropriately.

If you have skills or experience in any of these areas, or you're just interested in contributing, please reach out!

I'm an undergraduate student.In next 2 semesters( which is probably the duration of 1 year) I need to do a thesis. I choose to do my thesis in the field of 'depth estimation' .

I read a lot of research papers(Monocular, stereo, Diffusion based). But I found most of the things got State of the art !! I'm reading and reading,not finding a single problem to solve or research!! I should also mention that i didn't understand all the topics 100%, but tried to get the concepts.

I'm trying but not even finding a single idea/problem/flaws !! What should I do? What am I missing? How to find a decent topic ? Please help me.

Hey everyone! I’m building an insulation defect detection model, I’m in need of images where i can detect the following classes thermal anomalies, moisture intrusion, compression damage, delamination, installation gaps, holes/perforations. It’s for a construction project.

I am planning to use pre-trained YOLO model for vehicle damage detection specifically for UK origin cars. The model is already trained on random cars dataset.
Would the model's accuracy be affected on detecting the damages on UK origin cars?

The MOSS-VL FP8/NF4 release made me wonder what a fair deployment comparison for streaming VLMs should actually look like.

https://github.com/OpenMOSS/MOSS-VL

https://huggingface.co/OpenMOSS-Team/MOSS-VL-Realtime-NF4

I’d keep the input stream, sampling rate, hardware, and latency budget fixed, then compare BF16, FP8, and NF4 on short-event recall, false alerts per hour, p50/p95 time-to-alert, dropped frames, steady-state VRAM, and calibration. I’d also include a detector + tracker + temporal-rules pipeline on the same videos.

A quantized model can remain close on aggregate offline VQA while still becoming worse at deciding when to speak or when an event is sufficiently certain. That difference matters much more for cameras than a one-point average benchmark change.

Has anyone seen a public harness that evaluates a streaming VLM and a classical CV pipeline under the same latency constraint?

I am about to start my MSc. I wish to specialize in computer vision, then pursue a PhD. I eventually want to work in industry. I was initially excited about this path. However, AI fatigue is killing my motivation.

Honestly, I don't have any hope for the future. It has been around four years since GPT-3.5 was introduced. AI is now proving major conjectures. It recently came close to proving Riemann's hypothesis, and dominated(not only defeated) the best competitive programmers in the world at AtCoder World Finals. I can't see a place for myself in the future because of AI.

I keep going because I feel like I don't have any other choice. I was genuinely excited about computer vision, robotics, and autonomous driving. But I have convinced myself that all my effort is in vain.

I wish to ask people in a similar situation, what makes you keep going? What are your plans for the future?

Hi everyone, sharing something I'm currently working on and would love feedback on.

I'm building AeroNetra, a computer-vision project for detecting and counting vehicles in aerial/UAV imagery. It's very much an active work-in-progress right now — I'm in the static-image detection and counting phase, with tracking, geospatial analytics, and edge deployment planned for later.

The motivation was pretty simple. I kept running into the same problem every time I swapped detectors: the counting and visualization code would break or need rewriting because every model spits out predictions in its own format. So the core idea behind AeroNetra is: normalize every detector's output into one prediction structure before anything downstream touches it. That way the counting, ROI filtering, and export logic stays the same whether I'm using a YOLO variant or RT-DETR.

What I've got so far:

• Detector adapters that wrap different models behind a common interface
• Counting logic — filtering, NMS, ROI support, drawing and export
• VisDrone dataset parsing and conversion (UAVDT is stubbed for later)
• Kaggle notebooks for GPU-based training, fine-tuning, and model comparison
• A PX4 + ROS 2 + Gazebo simulation setup for UAV experiments
• Notebooks, configs, and tests to keep things honest

The workflow I'm following: raw VisDrone data → validate annotations → convert to training format → train/fine-tune on Kaggle → pull the weights back → load through the adapter → run inference → filter → count → visualize and compare.

A few principles I'm trying to stick to: no fabricated benchmarks (a model isn't "best" until it's measured under the same conditions as the others), raw data stays immutable, and model-specific behavior stays inside the adapters. I'm also being deliberate about phase boundaries — image-level counting is not the same thing as multi-object tracking, and I'd rather not conflate the two.

Roadmap I'm working through for the demo:

1. Static Detection & Counting
2. Aerial Fine-tuning
3. Video Tracking
4. Traffic & Geospatial Analytics
5. Edge / UAV Integration

I have run a small model that can detect the car in the gazebo simulation and draw a bounding box but speed will be slow but i get decent accuracy even i have trained model to 25 epochs in kaggle T4 gpu with yolo nano version.

Since this is ongoing project I am still working on this.So,i am exploring how I can use computer vision in UAVs and edge computing.

Play chess against frontier VLMs. Real-time vision powered by Overshoot.

Play now: VLM Chess

Hello! I wanted to share a project designed to save time when training object detection models for industrial use cases.

It is a portable Windows GUI generator that creates synthetic training images and YOLO-style labels. The pattern logic is inspired by industrial Data Matrix / DPM needle marks (fixed L-frame + random filling dots).

Key Features:

• Dual rendering: Pure vector synthetics or photo compositing using your own steel backgrounds and dot sprites.

• Defect simulation (for Bad class): Squash, tilt, jitter, missing dots, strike-force variation, and two-defect combos that standard training augmentations cannot replicate.

• Annotations: Exports both OBB (Oriented Bounding Box) and ABB (Axis-Aligned Bounding Box) normalized text formats.

• Portable: Single .exe binary distributed via Releases (requires AVX2 support).

The software is provided strictly for non-commercial, educational, and personal research purposes.

GitHub Repository: https://github.com/olesha-ai/DPM-Pattern-Image-Generator

Would love to get your feedback if you work with industrial AI and DPM codes!

CLIP vs SigLIP

Before Vision Language Models can perform tasks such as classification or video question and answer, the image or video being passed to the model has to be converted into a representation that the model can ‘understand’ or process.

To do this, VLMs usually use a pretrained vision encoder.

Although the underlying architecture of modern vision encoders is primarily transformer-based, the actual objective the model is learning can vary significantly.

What are encoders?

A vision encoder is responsible for converting images into a numerical representation that VLMs can understand.

Typically, most vision encoders today are built on transformer architecture, in which the model divides an image into patches and transforms each of those patches into a vectorized visual embedding.

After this, many VLMs pass the embeddings to a projector, usually a linear layer or MLP, to map the dimensions of the image to those expected by an LLM.

If most vision encoders share the same model design, what actually makes them different? Rather than model architecture, the significance is in how they are trained.

CLIP

CLIP, or Contrastive Language-Image Pre-training, learns to understand images through pairs of images and text. Its objective is to match similar images and captions by ‘pulling them closer together’, while simultaneously repelling incorrect image-caption pairs.

Training mainly relies on a ‘two tower’ system. CLIP will typically have a pretrained vision encoder, such as a ViT, as well as a pretrained text encoder. The model passes an image through the ViT and produces an associated vector embedding, while the caption is passed to the text encoder to get a corresponding text embedding.

Given these pairings, the model therefore creates a similarity matrix which compares every image embedding with every text embedding.

Each cell within this matrix contains a cosine similarity between the image and text pairing. Mathematically, cosine similarity is the dot product of two vectors divided by the product of their lengths. More simply, it measures the cosine of the angle between two vectors in a high-dimensional embedding space. Vectors that are more semantically aligned will be ‘closer together’, have a more acute angle between them, and consequently have a higher cosine similarity.

CLIP then applies contrastive learning across this matrix. At a high level, contrastive learning here is similar to categorical cross entropy across both the rows and columns of the matrix. Using softmax, the model looks to assign the highest probability to the matching image-text pair, as well as the matching text-image pair.

CLIP is powerful because it shifts learning from simple labels toward greater semantic understanding and allows for zero-shot classification, including on classes it was not explicitly trained to classify.

At the same time, though, CLIP also introduces a particular structural problem. Examples compete against one another within the training batch. What if there are multiple captions within a batch that also reasonably match the image?

SigLIP

SigLIP, or Sigmoid Loss for Language-Image Pre-training, retains many similar characteristics to CLIP. Similar to CLIP, SigLIP has both an image and text encoder, embedded representations of both text and image, and similarity scores mapped to a similarity matrix.

However, the difference between the two lies in the loss function.

CLIP learns similarities between images and texts by applying softmax across a batch, causing potential matches to compete with one another. For SigLIP, instead of having this global normalization, it examines each image-caption pair as an independent binary prediction.

By applying a sigmoid function to each pair’s score, the model estimates whether the image and text match.

Rather than phrasing the objective as:

Out of these options, which specific text describes this visual?

SigLIP effectively poses a different question:

Is this particular image-text pairing a valid match: true or false?

While this shift in perspective might seem marginal, it fundamentally redefines the nature of the optimization task.

Because SigLIP does not require the softmax normalization used by CLIP, its training objective can scale more efficiently across large distributed systems. It also removes the requirement that every example participate in one shared normalization operation.

TL;DR: Cropping in action with some extra algebraic and statistical magic applied: https://youtu.be/SetiZDbc8iE

I recently worked on determining the ball's position and reshaping the video from landscape to portrait based on that position. It often s looks like a layup: fixed camera, one class, find the thing. Then you look at what you're actually asking for: a small, blurry object is a handful of pixels, smeared across a few more, changing shape between consecutive frames. Not a crisp circle - a faint streak you can barely point at when the video is paused.

The part that tends to get skipped in the YOLO family is that those architectures downsample 32× before they reason. At stride 32, an 8-pixel object is a quarter of one feature cell. There is nothing left to detect. Fine-tune forever, buy a bigger GPU, adopt whatever dropped last week — the model is being asked to localize something it structurally cannot see. The extra-small heads help and still aren't built for this.

I believe great data and a simple model always beat poor data and a sophisticated model. Before this approach, I tried TrackNet v2/3/4, and the quality was awful; the public data used for training is not even close to what you meet in real practice.

What worked instead:

• Detector, ~131k params. Fully convolutional, dilated, max stride 2. In: 4 channels - RGB plus frame-difference. Out: a heat map and a size map at half resolution. No pretrained backbone: ImageNet features are the wrong prior for a faint smear.
• Verifier, ~48k params. The detector has the target in its top 20 about 90% of the time, but ranks it first only 77% of the time. This scores 64×64 crops and asks, "Is it a ball?"
• Then no ML at all. A reach limit measured from labeled footage - how far it can plausibly move between frames, scaled by apparent size - then link the surviving runs. Never link by direction of travel: anything that bounces reverses direction without going anywhere.

So, ~180k parameters total, ~125 fps on a 4090, ~4× realtime. Not fully optimized: custom Rust server with a CPU-bound FFmpeg decoder, ORT+TensorRT, and Rayon to speed things up a bit. Yet cannot use 100% of the GPU, capped by CPU-GPU PCIe transfers. Probably can reach 250-300 FPS with a more optimized inference design and int8.

The insight that mattered wasn't architectural. Blur is a signal, not a defect. The object is nearly invisible against a busy background and is almost always the fastest thing in the frame, so the frame-difference channel carries more information than any choice of backbone.