How do their APIs compare?

These two projects don't really have comparable "APIs" in the same sense — they serve fundamentally different purposes, so let me break down what each actually exposes.

chineseocr_lite: an OCR inference API

This is a user-facing, application-level API for running text detection/recognition:

• CLI interface: Per the README, it can be installed as a Python package and invoked as chineseocr test_imgs/res.jpg, with options like --output (JSON output path), --draw (annotated image output), and --compress (resize short side before detection). It also supports python -m chineseocr_lite module invocation.
• Output contract: The CLI returns a stable JSON structure with text (full recognized text), blocks (array of text segments with text, score, and box polygon coordinates), and elapsed timing — designed explicitly to be parsed by scripts or agents.
• Web service: backend/main.py starts a Tornado web server (default port 8089) exposing an HTTP/browser-based OCR demo, backed by backend/webInterface/__init__.py, which the import graph notes is one of the more central files.
• Native/JNI layer: On Android, the actual OCR pipeline is exposed through C++ JNI functions like the bitmap conversion routines in [android_projects/OcrLiteAndroidNcnn/OcrLibrary/src/main/cpp/src/BitmapUtils.cpp:L71-L107] (nMatToBitmap) and the core detection/recognition pipeline in [android_projects/OcrLiteAndroidNcnn/OcrLibrary/src/main/cpp/src/OcrLite.cpp:L71-L110], which chains dbNet.getTextBoxes, angleNet.getAngles, and crnnNet.getTextLines.

So its "API" is a thin, high-level surface (CLI/JSON, HTTP, JNI) wrapping an internal three-stage model pipeline (detection → angle classification → recognition).

Proton: a compatibility shim / generated interface layer

Proton has no equivalent "do a task, get JSON back" API. Instead, its most API-like code is lsteamclient, which exposes a generated 1:1 mirror of the Steamworks SDK's COM-style interfaces so Windows games can call Steam APIs under Wine:

• Files like [lsteamclient/cppISteamClient_SteamClient007.cpp:L246-L285], [lsteamclient/cppISteamClient_SteamClient017.cpp:L491-L530], [lsteamclient/cppISteamClient_SteamClient014.cpp:L491-L530], and [lsteamclient/cppISteamApps_STEAMAPPS_INTERFACE_VERSION009.cpp:L316-L355] each implement thin trampoline functions (e.g., GetISteamMusic, GetAppInstallDir, GetInstalledDepots, BIsAppInstalled) that unpack a params struct and forward the call to the real Linux-side Steam client interface.
• There's also parallel wow64_* variants of nearly every function (guarded by __x86_64__/__aarch64__), supporting 32-bit Windows games running under a 64-bit Wine/WoW64 layer — something chineseocr_lite has no analog for.
• These aren't hand-designed APIs; they're generated per Steamworks SDK version (hence versioned filenames like SteamClient007, SteamClient014, SteamClient017), acting purely as marshaling glue rather than business logic.

Key contrast

Aspect	chineseocr_lite	Proton
API purpose	Expose an OCR pipeline to end users/agents	Mirror an existing vendor API (Steamworks) for binary compatibility
Shape	High-level JSON/CLI/HTTP	Low-level ABI-matching C++ trampolines
Versioning	Single current pipeline	Multiple parallel versioned interfaces (007, 014, 017...) coexisting
Design origin	Hand-written application code	Largely generated marshaling code

I don't have visibility into additional public-facing API surfaces beyond what's shown (e.g., Proton's build configuration isn't an "API" per se — configure.sh [configure.sh:L36-L75, L246-L320] is a build script, not a runt