Three products, three launches:

• Scanner OCR — a barcode scanner that reads printed characters.
• Fixed-Mount OCR — a fixed-mount reader that reads text and grades code quality.
• Android OCR — an Android PDA that recognises text and fills it into the business app.

They look like three independent products. Open them up, though, and something interesting shows: they share the same OCR framework. It is not that three products look alike — it is one technology stack fitted into three hardware shells.

This is that framework, explained.

The three lines at a glance

Whatever device a customer has on the line, there is a matching form factor.

Inside the framework: one five-layer stack

Stack the three products and the same five-layer core emerges:

1
2
3
4
5
6
7
8
9
10
11
12

┌─────────────────────────────────────────────────────┐
│ ⑤ Output     focus entry · broadcast · records · custom formats │
├─────────────────────────────────────────────────────┤
│ ④ Rules      feature-template ROI + regex field extraction       │
├─────────────────────────────────────────────────────┤
│ ③ Engine     HappyLab OCRv6 (tiny / small)                       │
├─────────────────────────────────────────────────────┤
│ ② Vision     15-filter pre-processing library                    │
├─────────────────────────────────────────────────────┤
│ ① Capture  ← the only layer that differs per product             │
│              USB · FTP · camera / scan engine                    │
└─────────────────────────────────────────────────────┘

Only the bottom layer — Capture — changes with the hardware. The four layers above it (Vision, Engine, Rules, Output) are shared across all three lines. Adding a new device means writing a capture adapter; nothing above it moves.

Upgrade once, benefit three times

Because the core is shared, any improvement at any layer reaches all three product lines at the same time:

The real value of “one architecture” is not the development saved — it is that:

• Upgrade the model once → accuracy improves on all three lines.
• Tune the filters once → image quality improves on all three lines.
• Build a rule set once → a rule configured on one line can be reused on another.

Capability is no longer “one copy per product”. It is one capability pool, drawn on by all three.

Where each line is tuned

The core is shared, but each line pushes its own part to the limit.

🔫 Scanner — making the trigger pull feel native

• USB dual-mode (serial or HID); plug in and go.
• Single .exe, tray-resident, starts with Windows.
• Three engine tiers: v5 WebGPU / v6 tiny WebGPU / v6 tiny CPU (~60 ms, no GPU needed).
• ~350 ms end to end including focus entry — as seamless as scanning a barcode.

📦 Fixed-Mount — fully automatic, no operator

• Photoelectric IO trigger → reader captures → FTP push, with no human in the loop.
• A bounded queue absorbs irregular feed, dropping the oldest frame rather than blocking the device — the software is never the bottleneck.
• Two channels: ① OCR content, ② barcode grading (in-house C++, < 100 ms, following ISO/IEC 15416 / 15415 / 29158 conventions).
• The filename carries the barcode ({barcode}-{timestamp}-OK/NG), so that field comes at no extra cost.
• Throughput in the multi-frame-per-second range, capped by the reader’s trigger rate.

📱 Android — making it effortless

• Two capture modes: camera (CameraX) or the PDA’s built-in scan engine.
• Three triggers: physical scan key, a custom broadcast, or an on-screen floating ball.
• Accessibility focus injection into any business app, CJK included.
• Tablets too — tap the floating ball on a large screen and scan.

Why one framework matters commercially

A customer site may have scanners, fixed-mount readers and PDAs all at once. The traditional answer is one system per site: three codebases, three maintenance tracks, three upgrade paths.

With a single core:

1
2
3
4

One OCR framework
   ├── connect a scanner    → desktop OCR product
   ├── connect a fixed-mount → line OCR + grading product
   └── connect Android      → mobile OCR product

• Same recognition standard, same rule configuration, same maintenance for a partner to learn — across every device on the line.
• Maintenance cost goes from ×3 to ×1, while scenario coverage goes from 1 to 3.
• Extensible by design: a new device needs a capture adapter and an output adapter; the Vision, Engine and Rules layers stay untouched. The framework is not rebuilt — capability accumulates.

Looking ahead: ready for NPU-equipped PDAs

The three lines are the present. The framework’s real ambition is a smooth path to the next generation of AI-compute handhelds.

What an Android AI SoC looks like

A modern Android AI chip is a heterogeneous platform: a CPU for general logic and scheduling, a GPU for graphics and parallel work, an NPU for neural-network acceleration, an ISP for the capture path, and a DSP for signal processing and always-on low-power tasks.

Why the NPU matters for OCR

Why this framework can use an NPU without a rewrite

Android OCR runs a standard ONNX model on a standard Android inference stack — that choice is deliberate:

1
2
3
4
5
6

Today                          Tomorrow
────────────                   ────────────
ONNX model              →      the same ONNX model
ONNX Runtime (CPU)      →      ONNX Runtime + NNAPI / QNN provider
Software on CPU         →      Hardware-accelerated on the NPU
No application changes  →      No application changes, just faster

• Models are portable — ONNX is the common format for on-device AI, and mainstream NPUs support it.
• The framework doesn’t change — swap the execution engine beneath the Engine layer and the four layers above stay as they are.
• Capability can grow — tiny on CPU today, small on NPU tomorrow, an on-device model after that.
• Your investment holds — today’s PDAs work, and NPU-equipped PDAs are a seamless upgrade.

Recognition capability should not be frozen at the moment of purchase. Building the foundation at the software layer is what lets every hardware generation move all three product lines forward.

The bottom line

Three products, three launches — and under the hood, one engine.

• 🔫 Scanner: instant, trigger-driven capture.
• 📦 Fixed-Mount: unattended operation plus quality control.
• 📱 Android: scan anywhere, fill the field automatically.

They share the same Vision, Engine, Rules and Output capabilities, and adapt upward to different hardware, scenarios and systems: one framework, three product lines, upgrades shared across all of them.

Products and pricing

All licenses are one-time — no subscriptions. Full comparison on the pricing page.

💬 Questions or a custom requirement?

This global site is brand new, and our online tools are currently in Chinese. Tell us what you need and we’ll set up a fast, tailored solution for you — an English version is coming in the next few weeks.

📧 sales@happylab.me · 🌐 global.happylab.me

HappyLab builds practical AI and browser-based tools for industrial device workflows.