Turn any camera into a high-speed marking scanner

The Problem

Modern traceability is unit-level. Every pack of medicine, every bottle of dairy, every bottle of spirits carries an individual code, a DataMatrix, a QR, a serialized barcode. Read it, check it against the registry, log it, move on.

The bottleneck is the reading. Handheld scanners require one item, one trigger pull, one beep. Even with experienced operators, throughput is a few units per second per scanner. The scanner misreads, the operator manually corrects. Quality control happens by sampling, 10% of incoming units, 30% on a good day, because checking everything would stop the line.

Counterfeit and mis-scan risk goes up the further you are from the manufacturer. Pharmaceuticals are the obvious case (false drugs in the supply chain is a regulator problem and a public-health one), but alcohol, dairy, cosmetics, and any other category with mandatory marking face this risk too. The infrastructure for tracking is in place. The verification step is the human-shaped bottleneck.

What the Solution Does

A camera-based recognition system that reads all visible markings in a frame in real time. Operator points a camera (or smartphone, or fixed dock-mounted unit) at incoming product; the system detects, classifies, decodes, and validates every code it sees, simultaneously.

1. Capture, live video stream from a camera or phone.
2. Detect, a YOLO-based model finds DataMatrix, QR, and barcode regions in each frame.
3. Classify, a lightweight classifier (MobileNet) determines marking type and quality.
4. Decode and validate, codes are decoded, validated against expected format, and matched against the registry (your ERP, an external traceability system, or both).
5. Display and log, recognition results overlay the live image with confidence scores; verified records ship to ERP, WMS, or a downstream compliance system.

Where It Fits

This makes sense if you…

• Process goods that carry unit-level marking (pharma, dairy, alcohol, cosmetics, tobacco, any traceability-regulated category)
• Have throughput that handheld scanning struggles to keep up with
• Need 100% verification of every unit for compliance reasons, where sampling no longer suffices
• Want recognition at the edge, without sending video to foreign clouds
• Can integrate via REST API into your existing WMS / ERP

This is probably not the right time if you…

• Move goods that don’t carry standardized markings yet, the SDK reads codes, it doesn’t create them
• Process at low enough volume that handheld scanners aren’t a bottleneck (more common than people think, so check your real throughput first)
• Need OCR of printed text labels (a different problem, document data extraction)
• Need anti-counterfeit verification based on something other than the marking itself (materials analysis, hologram detection, different problem)

Business Value

Speed. The system processes a full camera frame, every marking it can see, in roughly the time a handheld scanner reads one code. In documented deployments we see around 3x throughput improvement against sequential manual scanning. The benefit grows as the per-unit batch size grows; on a conveyor or a multi-unit pallet, the gap is much larger.

Coverage. Manual operations almost always sample (10-30% of incoming units is typical for QA). Camera-based recognition is a 100% verification goal, every code on every visible unit gets read. This changes the compliance picture in regulated categories from “we checked a sample” to “we verified every unit”.

Accuracy. Trained marking types hit 99-99.7% recognition accuracy in production, measured on a published client deployment. Note: this is best-case on trained marking standards. Unusual or damaged markings (heavily scratched DataMatrix, faded ink on aged stock) score lower. The system flags low-confidence reads and holds off on a guess.

Sovereignty. Inference runs on the edge or on-prem (we use OpenVino for CPU inference, no GPU required, no foreign cloud dependency). For pharma and other regulated verticals where data residency matters, this is often the requirement that rules out international SaaS competitors.

How It Works

The five-stage pipeline below is what shipped to a national product-marking operator: a national track-and-trace system for mandatory marking.

1. Image capture

Live video from a USB / IP camera, smartphone front or rear camera, or fixed dock-mounted industrial camera. The SDK supports MediaPipe and standard video streams; integration into existing apps is a couple of days of work.

2. Marking detection (YOLOv5s)

A YOLO-based detector scans each frame and produces bounding boxes for every visible marking, DataMatrix, QR, EAN-13, Code 128, anything we’ve trained on. We use YOLOv5s as the backbone for the base model because the size/speed trade-off matches edge deployment.

3. Marking classification (MobileNetV2)

Each detected region is passed through a lightweight classifier to determine the marking type (so the right decoder runs next) and to assess marking quality (is it clean enough to decode reliably, or should we flag it?).

4. Decoding and aggregation

Detected codes are decoded using standard libraries plus our own post-processing for damaged or partial codes. If multiple markings appear on one item (a product carton with both a DataMatrix and a serialized barcode), the system unifies them into one logical record before writing to the ERP.

5. Validation and integration

Decoded codes are validated against expected format, optionally checked against the registry (national product-marking operator, GS1, customer-side registries, or the customer’s own WMS database), and the verified record ships through a REST API into your ERP / WMS workflow. Failed validation triggers a flag for human review.

Stack

YOLOv5s (detection), MobileNetV2 (classification), TensorFlow Lite for on-device inference, OpenVino for CPU inference on customer servers (no GPU required for the base model), MediaPipe for the real-time pipeline, OpenCV for preprocessing, FastAPI for the integration layer.

What You Need to Make This Work

Data. For standard marking types (DataMatrix per GS1, EAN-13, QR), the base model is ready. For unusual conditions, damaged stock, custom packaging, regional standards, expect a 1-2 week data collection sprint during the test.

Integrations. Read access to the markings registry you validate against (national product-marking operator API, GS1, or your internal master). A REST endpoint into your WMS / ERP for verified records. For mobile deployment: SDK integration into your iOS / Android app.

Hardware. Off-the-shelf USB or IP cameras (no special industrial spec needed for most use cases). Mid-range CPU servers, no GPU required for the base model. For mobile: any modern smartphone with rear camera.

Team. A receiving-ops or QA lead who’ll own the workflow. A WMS / IT contact for integration (~15-25 hours during pilot). Operator training is short, the UX is “point camera, look at screen”.

Implementation Roadmap

1. Test (3-6 weeks)

Set up the SDK on a sample camera at one location. Collect data on your actual marking conditions (which standards, what condition they’re in, how cluttered the frames are). Measure baseline accuracy on your data. Define the ERP integration spec. Output: written report with measured accuracy, list of marking types ready vs. needing additional training, integration scope for pilot.

2. Pilot (2-3 months)

Production deployment to one workflow (one dock, one line, or one mobile app). Train any additional marking types found during test. Build and harden the ERP integration. Train operators. Measure throughput and dispute reduction against baseline. Output: working production deployment at one site, documented business metrics, go/no-go on rollout.

3. Production (3-6 months)

Roll out to additional sites or mobile devices. Periodic retraining as new marking variants appear. Quarterly accuracy review. Your team owns day-to-day; we stay on for retraining cycles and edge cases.

Keep in Mind

The limits, stated plainly:

• It reads markings; it doesn’t authenticate goods. Recognizing “this DataMatrix decodes to SKU 12345” is different from “this DataMatrix is genuine and corresponds to a real registered unit”. Authentication requires registry validation, which we plug into. The registry is the source of truth here; the SDK only reads the code.
• Damaged codes will fail. A heavily scratched, faded, or torn marking can’t be decoded by any vision system. The SDK flags low-confidence reads and holds off on a guess, so you keep an operator workflow for exceptions.
• Trained-vs-untrained matters. Accuracy numbers are for marking standards the model has seen. A new regional standard or a custom in-house code needs training data and a short retraining cycle.
• Edge deployment has memory constraints. The base model fits comfortably in CPU memory; aggressive customization for unusual decoder pipelines can push that up. We size during the test phase.
• 3x faster is on average. Single-unit handheld scanning is fast for one unit. Where camera-based recognition wins is on batches, pallets, conveyors, multi-unit frames. Don’t expect the 3x on a workflow that scans one unit every five minutes.

FAQ

Which marking standards do you support?

DataMatrix (GS1), EAN-13, EAN-8, UPC-A, Code 128, Code 39, QR Code, PDF417, plus a number of regional variants. The list grows; new standards take 2-4 weeks to add via the training pipeline.

Can this run fully offline?

Yes. The base inference stack uses OpenVino on CPU, no internet, no GPU, no foreign cloud. Registry validation requires connection to the registry (which is by definition an external dependency), but the recognition itself is offline-capable.

Is this an SDK or a service?

Both. We ship an SDK for integration into your mobile or warehouse application; we also operate a hosted service for clients who want a ready-to-use REST API with no setup on their side. The decision depends on your data residency requirements.

How does this compare to commercial scanner SDKs (Scandit, Cognex, etc.)?

Commercial SDKs are excellent and we sometimes recommend them when the use case fits their licensing model. Our SDK is the right choice when you need: heavy customization for unusual marking conditions, regional standards not well-supported by commercial vendors, fully on-prem deployment with no cloud telemetry, or integration with a specific traceability registry that requires custom decoding logic.

What about counterfeit detection?

Reading the marking and verifying it against a registry catches “this code isn’t registered” or “this code was already used elsewhere”, which is most of the counterfeit story in pharma and similar regulated categories. Physical counterfeit detection (is this packaging printed by the real manufacturer?) is a separate problem that requires materials-level analysis.

Ready to Discuss?

If you handle volume of regulated-marking goods and the manual scanning workflow is a bottleneck or a compliance risk, this is a relevant conversation. We’ll walk through your marking standards, your throughput, and your registry integration, and tell you whether the SDK or a commercial alternative is the better fit for your specific case.

Discuss your project