light-ocr: Offline-Texterkennung mit PP-OCRv6 Small für Node.js und C++
Schnelle Offline-OCR für Node.js und C++. PP-OCRv6 mit Core ML/WebGPU-Hardwarebeschleunigung, erkennt Text in Bildern mit Konfidenzwerten und Koordinaten. npm: @arcships/light-ocr.
Auf einen Blick
- Was ist das?
- arcships/light-ocr erkennt Text in PNG, JPEG und PDF lokal, liefert Konfidenzwerte und Viereckkoordinaten und bringt PDFium samt Noto-Sans-SC-Ausweichschrift im npm-Paket mit. Stand v0.5.7.
- Für wen ist es gedacht?
- light-ocr passt zu Node.js-Anwendungen unter Version 22 oder 24 und zu C++-Projekten, die Texterkennung ohne Netzwerk und ohne Nachladen brauchen, etwa bei sensiblen Scans oder in abgeschotteten Umgebungen. Weniger geeignet ist es, wenn Japanisch gebraucht wird, weil die Vorschaustufe Tiny diese Sprache auslässt, oder wenn höchste Erkennungsgüte ohne eigenen Build erwartet wird.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 42 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
light-ocr: PP-OCRv6 Small lokal in Node.js und C++
light-ocr von arcships ist eine OCR-Bibliothek für Node.js und C++, die ohne Netzverbindung arbeitet. Sie liest Text aus JPEG, PNG, PDF sowie aus kodierten Bytes oder dekodierten Pixelpuffern und gibt Zeilen in Lesereihenfolge zurück, jede davon mit Text, Konfidenzwert und Viereckkoordinaten.
Laut README enthält das npm-Paket das Modell PP-OCRv6 Small, PDFium, eine chinesische Ausweichschrift und vorgefertigte Komponenten für macOS, Linux und Windows, ohne Postinstall-Skript und ohne Nachladen beim ersten Start.
Das Repository arcships/light-ocr steht unter Apache-2.0, zählt 489 Sterne und 41 Forks bei 2 offenen Issues. Das jüngste Release v0.5.7 erschien am 5. August 2026, die Vorgänger v0.5.6 und v0.5.5 im Juli.
npm install @arcships/light-ocr und createEngine() unter Node.js 22 und 24
Der Einstieg beginnt mit npm install @arcships/light-ocr; unterstützt werden Node.js 22 und 24. Im Code erzeugt createEngine() eine Engine, danach nimmt recognizeEncoded() den Inhalt einer Bilddatei entgegen. Zurück kommt ein Objekt, dessen Feld lines pro Zeile text, confidence und box liefert. Am Ende schließt engine.close() die Ressourcen, im README als finally-Block gezeigt.
createEngine() wählt den Ausführungspfad selbst. Wer Bilder bereits dekodiert hat, nutzt recognize() mit Pixeldaten in den Formaten GRAY8, RGB8, BGR8 oder RGBA8 und spart sich das erneute Dekodieren.
Dieselben Exporte stehen in CommonJS über require sowie in ESM und TypeScript bereit; am Paketnamen ändert sich dadurch nichts.
recognizeEncoded, recognize und recognizeDocument mit schemaVersion 1
Für Dokumente dient recognizeDocument(). Der Aufruf recognizeDocument("report.pdf", { dpi: 200 }) liefert einen asynchronen Iterator über die Seiten: page.index nennt die Position, page.lines die erkannten Zeilen, page.source.kind die Herkunft. Statt eines Pfads nimmt die Funktion auch ein Array von Bildpuffern an, womit sich mehrere Scans zu einem Dokument zusammenfassen lassen.
Das Ergebnisschema ist versioniert und trägt schemaVersion: 1, was Auswertungen über Paketversionen hinweg erleichtert. Die EXIF-Orientierung korrigiert die Bibliothek nach Auskunft des README selbsttätig.
Zur Laufzeit arbeitet die Erkennung außerhalb des JavaScript-Hauptthreads; Warteschlangen, Abbruch und ein explizites Aufräumen sind vorgesehen, sodass eine Desktop-Anwendung unter Last bedienbar bleibt.
Die light-ocr-CLI: detect, --region und doctor --json
Nach der Installation steht der Befehl light-ocr ohne weitere Einrichtung bereit. light-ocr image.png --format json liefert Text samt Koordinaten, --format text nur den Text, --format jsonl streamt zeilenweise. Bei PDFs begrenzt --pages 1-10 den Bereich, ohne diese Option arbeitet die CLI mit 150 DPI.
Weitere Unterbefehle sind detect für reine Textregionen ohne Erkennung, info --version für die Engine-Version und doctor --json für eine Systemdiagnose mit Hardware und Anbietern. Ein Pfad mit der Endung .pdf führt unmittelbar zur Dokumentenerkennung; document fasst mehrere Quellen zusammen, etwa light-ocr document scan1.png scan2.png.
Für einen Ausschnitt sorgt --region 100,80,640,320. Die vollständige Referenz liegt in docs/cli-design.md und in der Paket-Readme unter packages/light-ocr/README.md.
PDFium und Noto Sans SC im selben Plattformpaket
Die PDF-Verarbeitung gehört zum Kern des Pakets. Laut README werden das passende PDFium-Binärprogramm und eine per Prüfsumme festgelegte Ausweichschrift Noto Sans SC im selben plattformspezifischen npm-Paket mitgeliefert wie die OCR-Laufzeit. Damit bleiben PDFs darstellbar, die verbreitete nicht eingebettete chinesische Schriften referenzieren, und zwar vor der Erkennung.
Der Verzicht auf Nachladen ist ausdrücklich Teil des Konzepts: kein Postinstall-Skript, kein Laufzeit-Download, kein Compiler, keine Systemschrift, kein zusätzliches Paket. Für Umgebungen ohne Netzwerkzugang macht das den Unterschied.
Für sehr kleine Schrift in hochauflösenden Bildern hält das README einen optionalen Modus namens tiled bereit, der die Fläche in Kacheln zerlegt.
Sechs Plattform-Builds: Core ML, WebGPU über Vulkan und D3D12
Sechs Plattform-Builds stellt das npm-Paket bereit. Im Auto-Modus versucht light-ocr auf Apple Silicon mit macOS 15 oder neuer zuerst Core ML, auf Intel-Macs bleibt es bei der CPU. Unter Linux x64 mit glibc führt der Weg über WebGPU auf Basis von Vulkan, unter Linux arm64 direkt zur CPU. Windows x64 nutzt WebGPU über D3D12, Windows arm64 die CPU. Fällt der beschleunigte Pfad weg, folgt jeweils der CPU-Pfad. Wer den Pfad selbst bestimmen will, setzt die Option execution auf auto, cpu, apple oder webgpu.
Zur Wirkung nennt das README Messungen aus Version 0.3.0, ausdrücklich als Vergleich auf derselben Maschine gegen den CPU-Pfad und selbst berichtet. Auf einem Apple M4 Max mit Core ML sank die CPU-Zeit des OCR-Schritts um 95,91 bis 97,67 Prozent; die Ende-zu-Ende-Beschleunigung lag bei 2,30x bei einem einfachen Bild und 2,85x bei einem dichten Formular. Eine NVIDIA RTX 5060 Ti erreichte unter Linux mit WebGPU über Vulkan 5,70x über 14 Testbilder, eine AMD Radeon 780M unter Windows 2,44x. Für spätere Versionen liegen keine gleichwertigen Werte vor.
Modellstufen Small, Tiny und Medium mit 30 MB, 6,3 MB und 139 MB
Bei den Modellstufen bleibt Small mit rund 30 MB der stabile Standard. Tiny über @arcships/light-ocr-tiny@next bringt etwa 6,3 MB mit, deckt 49 Sprachen ab, jedoch kein Japanisch, und gilt als Vorschau. Medium über @arcships/light-ocr-medium@next umfasst rund 139 MB, ist ebenfalls Vorschau und als qualitätsorientiert positioniert.
Alle drei Stufen teilen API, Typen, Ergebnisschema und Fehlermodell, und jede Installation enthält nur das gewählte Modell. Für einen Wechsel genügt ein anderer Paketname, sofern Vorschauversionen tragbar sind.
Ein Hinweis gilt Verteilern unter macOS: Die Ladekomponente akzeptiert neu signierte Mach-O-Dateien, wenn die Signatur prüfbar ist und die Identität zur Wirtsanwendung passt, gleiches TeamIdentifier oder beiderseits Ad-hoc. Andere Plattformen behalten die strenge Prüfung über Größe und SHA-256.
Cloud-Dienste und light_ocr::core als Alternativen, dazu Apache-2.0
Als Alternative zu @arcships/light-ocr kommt ein Cloud-Dienst für Dokumentanalyse in Frage. Der Unterschied liegt im Datenweg: Bei light-ocr bleiben Bilder und Ergebnisse auf dem Rechner, was für vertrauliche Scans zählt, während ein Dienst eine Übertragung verlangt und die Nutzung an Kontingente bindet.
Als zweiter Weg bietet sich die C++-Seite des Projekts an. Aus dem Quelltext entsteht eine statische Bibliothek, verlinkt über das CMake-Ziel light_ocr::core, mit derselben Pixel-API auf GRAY8, RGB8, BGR8 und RGBA8. Dieser Pfad kostet einen eigenen Build, vermeidet aber vorgefertigte Binärdateien aus dem Paket.
Die Lizenz ist Apache-2.0 inklusive Patentregelung; Gewährleistung und Support sind ausgeschlossen. Offen bleiben die Trainingsdaten des Modells, Angaben zur Genauigkeit über die selbst berichteten 0.3.0-Messungen hinaus sowie Zusagen zur Weiterentwicklung.
Redaktionelles Fazit
light-ocr passt zu Node.js-Anwendungen unter Version 22 oder 24 und zu C++-Projekten, die Texterkennung ohne Netzwerk und ohne Nachladen brauchen, etwa bei sensiblen Scans oder in abgeschotteten Umgebungen. Weniger geeignet ist es, wenn Japanisch gebraucht wird, weil die Vorschaustufe Tiny diese Sprache auslässt, oder wenn höchste Erkennungsgüte ohne eigenen Build erwartet wird. Vor der Festlegung empfiehlt sich ein Probelauf mit light-ocr doctor --json, um zu sehen, ob auf der Zielmaschine tatsächlich Core ML oder WebGPU greift, dazu ein Vergleich von recognizeDocument mit dpi 200 gegen die eigene Vorlage.
Community-Notizen