daybreak-u / chineseocr_lite

Code

Understand daybreak-u/chineseocr_lite's source layout and find a starting point for your task using the saved repository evidence.

Architecture grade

score 100/100

Import cycles

lower is better

Modules parsed

5 edges

100%

Layeredness

clean-layer ratio

Measured from the parsed import graph, retained from the earlier analysis. Coupling, not a reading order.

How the code fits together

Native Core (C++)Lightweight OCR inference engine built on MNN framework with three specialized neural networks.
Android JNI LayerKotlin/Java bridge providing high-level OCR API to Android applications.
MNN Inference FrameworkPre-built MNN library headers and model files for efficient mobile inference.
Demo ApplicationAndroid reference app demonstrating OCR integration and UI interaction patterns.
Build & DependenciesGradle configuration and CMake build setup for Android NDK compilation.

Files at 54a3df53af82 · descriptions are AI-written.

Where to start reading

Repository root
Repository root
Public API candidatename match
Public API candidatename match
Runtime candidatename match
Runtime candidatename match
Suggested starting pointAI

Find files for a task

Add a new OCR model variant

Suggested by the saved analysis. Some step paths were not captured or refer to generated or vendor files; only observed source files are linked.

Add model initialization and inference calls to OcrLite.cpp main orchestrator
Update CMakeLists.txt to compile new source file

Support a new inference framework (beyond MNN)

Suggested by the saved analysis. Some step paths were not captured or refer to generated or vendor files; only observed source files are linked.

Add conditional CMake rules in CMakeLists.txt to build against selected framework

Add OCR result post-processing rule

Suggested by the saved analysis. Verify the proposed change against these source files.

Define new filter logic in OcrResultUtils.cpp following existing text cleaning patterns
Expose filter function signature in OcrResultUtils.h header
Call new filter in OcrLite::detect() or OcrLite::recognize() pipeline
Test via demo app GalleryActivity or add unit test in androidTest

Change the public API

Start with possible export surfaces, then check their consumers and tests. These suggestions use file names, not verified execution paths.

File-name match for this task.
File-name match for this task.
File-name match for this task.

Trace runtime behavior

Start with possible startup or request handlers, then follow the calls for your scenario. These suggestions use file names, not verified execution paths.

File-name match for this task.
File-name match for this task.
File-name match for this task.

Add or update tests

Use a nearby test as a pattern. Read the root manifest or contribution guide for the correct test command. These suggestions use file names, not verified execution paths.

File-name match for this task.
File-name match for this task.
File-name match for this task.

Change build or automation

Inspect the relevant configuration and the commands it runs before changing the workflow. These suggestions use file names, not verified execution paths.

File-name match for this task.

File paths come from a snapshot of up to 500 captured paths; an omitted file may still exist.

Public and runtime candidates are based on file names; their exports and execution paths still need checking in source.

Import graph details

Modules (3)

Source directories grouped from the import graph. Each links to a per-module page with its files and how it couples to the rest.

chineseocr_lite3 files · 2 in-degree
angnet2 files · 1 in-degree
backend/webInterface2 files · 1 in-degree

Architecture and request flow

Critical modules — by import-graph evidence

Import graph

13 files parsed · 5 internal edges

A file is "critical" when lots of other files in the repo import it. The list is sorted by how many files import each one; the top of the list is the most load-bearing. A flame icon means the file is also one of the most-edited recently — when a critical file changes a lot, bugs there ripple wider, so it's where regressions are most likely.

How the A grade breaks down

Imports flow one direction100%

40/40

What fraction of imports go from application code (likely to change) toward foundation code (more stable). High % means the codebase has clean layers — like a pyramid, not a hairball. Healthy repos are above 85%.

Foundation vs application separationspread = 0.50

30/30

Measures how distinct foundation files (rarely change, lots of files depend on them) are from application files (change often, depend on lots of things). A wider spread (higher σ) means clearer layers; a narrow spread means everything's tangled together at roughly the same level.

No circular imports0 cycles

30/30

A 'cycle' is when file A imports B which imports A again (possibly via more files in between). Cycles make builds slower, refactors harder, and tests trickier. −5 points per cycle found.

List — top 12 most-imported files

Architecture evolution

See how the import graph changed in the last 90 days — grade shift, cycles added/removed, top-file rotation. Heavy compute (~30s on first load), cached for 30 days after.

Possibly-unused modules (4)

Import graph

Nothing else in the repo imports these files, and they don't look like entry points — so they may be dead code. Verify before removing: dynamic imports, re-exports, and framework auto-loading (Next.js routes, plugin/DI registries) aren't tracked by the import graph.

isolatedbackend/np_encoder.py

isolatedbackend/webInterface/tr_index.py

unreferencedbackend/webInterface/tr_run.py

unreferencedtests/test_cli.py

Request flow

Technology choices

MNN Inference Framework

Ultra-lightweight mobile-optimized framework enabling <5MB total model footprint with CPU-only inference (no CUDA required).

C++ Native (NDK)

Critical for real-time image processing performance; avoids Java/Kotlin JVM overhead for model inference and tensor operations.

Android JNI Bridge

Decouples high-performance C++ inference from Kotlin UI layer, allowing framework agnostic model swapping (MNN/ONNX/TNN).

DBNet + CRNN + AngleNet architecture

Specialized three-stage pipeline: detection (DBNet 1.8M) → orientation (AngleNet 378KB) → recognition (CRNN 2.5M) optimizes for Chinese text including vertical scripts.

Build time and runtime

Build-time

▸
CMake NDK Compilation — Compiles C++ sources (OcrLite, DbNet, CrnnNet, AngleNet, clipper) against MNN headers targeting armeabi-v7a and arm64-v8a ABI.
▸
Gradle Library Build — Packages compiled .so libraries, Java/Kotlin JNI wrappers, and .mnn model assets into AAR for consumption by Android apps.
▸
Model Asset Bundling — Embeds pre-trained dbnet.mnn (1.8M), crnn_lite_lstm.mnn (2.5M), angle_net.mnn (378KB) in APK assets directory.

Runtime

▸
MNN Model Loading — On OcrEngine initialization, MNN Interpreter deserializes .mnn files from app assets into memory (total ~4.7MB).
▸
Inference Pipeline — For each input image: angle detection → 90/180/270° rotation correction → text region detection (DbNet) → character-level recognition (CrnnNet) with confidence filtering.
▸
Image Pre/Post Processing — Bitmap conversion (ARGB→RGB), resize to model input dimensions, polygon clipping of detected boxes, character decoding via keys.txt lookup.
▸
Result Serialization — OcrResult Kotlin data class serialized to JSON for passing between JNI layer and UI (GalleryActivity).

Design trade-offs

CPU-only inference (no GPU support in listed files)

Maximizes device compatibility and reduces memory footprint for embedded/low-end Android devices.

Inference latency higher than GPU-accelerated alternatives; suitable for <30fps processing, not real-time video.

Fixed pre-trained models without fine-tuning hooks

Reduces binary size and deployment complexity; targets standard Chinese OCR use cases.

Cannot adapt to domain-specific scripts or handwriting without retraining models externally.

Character vocabulary in keys.txt (static lookup table)

Eliminates softmax decoding overhead; outputs are direct character indices.

Cannot recognize characters outside pre-defined vocabulary; requires retraining for custom character sets.

Single-threaded sequential pipeline (DbNet → AngleNet → CrnnNet)

Simplifies memory management and avoids synchronization complexity on mobile.

Cannot parallelize detection + recognition of multiple regions; unused CPU cores during inference.

Non-goals

✗Real-time video stream OCR (no frame buffering or temporal consistency)
✗GPU inference acceleration (CUDA, Metal, Vulkan not integrated)
✗Fine-tuning or transfer learning APIs (inference-only engine)
✗Multi-language support beyond Chinese (English alphanumerics supported via keys.txt, but not Latin script optimization)
✗Cloud/server deployment (Android/mobile-first focus; Python backend is separate module)
✗Handwriting or document photo OCR (trained on printed/digital text)

Code quality and hotspots

Quality Score: 70/100

Low Risk

This repo is in good health with CI, tests, and active maintenance.

No CI -20High complexity -10

Maintainability grade

Static analysis

How maintainable the code looks — from complexity, code issues, test presence, file size, and hotspot load. It grades the shape of the code, not defect risk, and doesn't replace review.

41/100

A ≥ 85, B ≥ 70, C ≥ 55, D ≥ 40, F < 40

Cyclomatic complexityavg 314

0/35

Code issues0 errors, 8 warnings

17/20

Testspresent · ~4% of files

14/20

Largest file4,630 lines

0/15

Hotspot load0 high-risk files

10/10

Configuration status

CI/CD Pipeline — not detected

Regression risk without automated builds

Add GitHub Actions CI

Test Suite — detected

7 test files detected

Stack: Pytest

Where: android_projects/OcrLiteAndroidMNN/app/src/test/java/com/benjaminwan/ocr/onnx · android_projects/OcrLiteAndroidMNN/OcrLibrary/src/test/java/com/benjaminwan/ocrlibrary · android_projects/OcrLiteAndroidNcnn/app/src/test/java/com/benjaminwan/ocr

Test Coverage — ~4%heuristic

7 test files / 179 source files. This is a file-count ratio, not real line coverage — set up Codecov for authoritative numbers.

Dependency Scanning — no config detected

No Dependabot / Renovate / Snyk / Trivy / CodeQL config found. Enable Dependabot or Renovate.

Live Signals

Real-time data from Codecov, GitHub Actions, GitHub Issues, deps.dev — not estimates.

CI pass rate100%

last 3 runs · median 49s

Stale-issue ratio74%

of 27 recent open issues are 30d+ old with no replies

Maintainer response24h

median first-reply across 9 recent issues · fast

Activity trajectory↓ Declining

last 6mo: 23 commits · prior 6mo: 39

Top hotspots

Files edited often AND hard to reason about. Churn = recent commit frequency, Complexity = branches and nesting, Risk = both combined. These are the highest-leverage targets for refactoring or testing.

src/clipper.cpp

Churn: 0 (0 commits/180d)Complexity: 100Risk: 0

src/clipper.cpp

Churn: 0 (0 commits/180d)Complexity: 100Risk: 0

All hotspots

Files that change often and are complex tend to accumulate more bugs

Code metrics

Static analysis on sampled source files (up to 15 files).

Avg Cyclomatic Complexity314

Counts if/for/while/switch/catch/ternary branches

Errors / Warnings0 / 8

Secrets, empty catches, console.log, var usage, long lines

Largest File Analyzed4630 lines

cpp_projects/OcrLiteMnn/src/clipper.cpp