light-ocr : OCR hors ligne pour Node.js et C++
OCR rapide et hors ligne pour Node.js et C++. PP-OCRv6 avec accélération matérielle Core ML / WebGPU, reconnaissez le texte dans les images avec des scores et des coordonnées de confiance. npm : @arcships/light-ocr.
En bref
- De quoi s’agit-il ?
- Reconnaissez le texte dans les images et les PDF localement, avec scores de confiance et coordonnées quadrilatères, accéléré par Core ML et WebGPU.
- À qui s’adresse-t-il ?
- light-ocr s'adresse aux personnes qui acceptent d'examiner `npm install @arcships/light-ocr` et les artefacts produits avant une intégration. Il convient moins à un usage qui exige une garantie non documentée ou une dépendance entièrement invisible.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 42 jours.
- En quel langage est-il écrit ?
- Principalement C++, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Positionnement et fonctionnalités principales
light-ocr est une bibliothèque OCR hors ligne destinée à Node.js et C++. Elle reconnaît le texte dans les PDF, JPEG, PNG ou données d'image brutes directement sur la machine locale, en renvoyant des lignes dans l'ordre de lecture avec un score de confiance et des coordonnées quadrilatères pour chaque ligne. Selon le README, le paquet Node.js inclut le modèle PP-OCRv6 Small, PDFium, une police de secours chinoise et des composants précompilés pour macOS, Linux et Windows, sans téléchargements post-installation ni au premier lancement. Cette conception supprime les étapes habituelles de téléchargement de modèle et de scripts postinstall, rendant la capacité OCR disponible via un seul npm install.
Dans light-ocr, le contrôle 1 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 1 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
Démarrage rapide et utilisation de l'API
Le README montre le chemin le plus simple : installer @arcships/light-ocr via npm, appeler createEngine() dans Node.js, puis utiliser recognizeEncoded() pour lire un fichier image et le reconnaître. Le tableau lines résultant contient le texte, la confiance et la boîte pour chaque ligne. Si une application décode déjà les images, recognize() accepte également les données de pixels GRAY8, RGB8, BGR8 et RGBA8. Pour les PDF, recognizeDocument() est utilisé et diffuse les pages une par une. Les mêmes exports fonctionnent en CommonJS via require(). Le README indique que Node.js 22 et 24 sont pris en charge, mais ne précise pas si d'autres versions fonctionnent.
Dans light-ocr, le contrôle 2 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 2 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
Outil en ligne de commande
Après installation, la commande light-ocr est disponible sans configuration supplémentaire. La CLI prend en charge plusieurs opérations : recognize (par défaut, texte plus coordonnées), detect (régions de texte uniquement), info (version du moteur) et doctor (diagnostic système incluant matériel et fournisseurs). Les formats de sortie incluent json, text et jsonl, json utilisant un contrat versionné schemaVersion: 1. Un chemin .pdf route directement vers l'OCR de document, et une commande document gère les travaux multi-sources explicites. Les exemples montrent --region pour une région d'intérêt et --pages pour une plage de pages PDF. Le README renvoie à docs/cli-design.md et au README du paquet npm pour la référence complète.
Dans light-ocr, le contrôle 3 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 3 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
Gestion des PDF et documents multipages
L'OCR PDF et multipages est intégrée à @arcships/light-ocr. Le README souligne que le binaire PDFium correspondant et une police de secours Noto Sans SC à somme de contrôle fixe sont fournis dans le même paquet npm de plateforme que le runtime OCR. Cela permet de rendre les PDF référençant des polices chinoises courantes non intégrées avant l'OCR, sans script postinstall, téléchargement à l'exécution, compilateur, exigence de police système ou paquet séparé. La CLI peut traiter un PDF unique ou une plage de pages et émettre des flux JSONL. Dans l'API programmatique, recognizeDocument() accepte un chemin PDF ou un tableau de tampons d'image et diffuse les résultats de chaque page. Ces détails placent le support PDF au cœur du paquet plutôt que comme un ajout.
Dans light-ocr, le contrôle 4 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 4 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
Accélération matérielle et niveaux de modèles
L'appel par défaut createEngine() utilise le mode Auto, choisissant un chemin d'exécution selon la plateforme. Il essaie d'abord Core ML sur Apple Silicon macOS 15+, puis WebGPU sur Linux x64 avec glibc et Windows x64, avec repli CPU ailleurs. Les applications nécessitant un contrôle explicite peuvent choisir auto, cpu, apple ou webgpu via l'option execution. Côté modèles, Small est le défaut stable à environ 30 Mo, tandis que Tiny et Medium sont des paquets d'aperçu opt-in sous le tag next, à environ 6,3 Mo et 139 Mo. Les trois exposent la même API, types, schéma de résultats et modèle d'erreur, mais chaque installation ne contient que le modèle sélectionné. Tiny prend en charge 49 langues sans japonais, et Medium est positionné comme priorité à la qualité.
Dans light-ocr, le contrôle 5 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 5 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
L'étendue des performances mesurées
Le README inclut un ensemble de mesures pour la version 0.3.0, réalisées sur trois appareils réels en comparaison sur la même machine avec le chemin CPU. Sur un Apple M4 Max avec Core ML, le temps CPU du processus OCR a diminué de 95,91 % à 97,67 %, et l'accélération de bout en bout était de 2,30x sur une image simple et 2,85x sur un formulaire dense. Sous Linux, une NVIDIA RTX 5060 Ti utilisant WebGPU/Vulkan a atteint une accélération globale de 5,70x sur 14 images de test avec environ 70 % de temps CPU en moins. Sous Windows, une AMD Radeon 780M utilisant WebGPU/D3D12 a atteint une accélération globale de 2,44x avec environ 46 % de temps CPU en moins. Le README indique clairement qu'il s'agit de comparaisons sur la même machine et que les résultats varient selon la charge et le matériel, et il fournit un lien vers le rapport complet de la version 0.3.0. Aucune donnée de performance équivalente n'est fournie pour les versions ultérieures.
Dans light-ocr, le contrôle 6 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 6 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
Intégration C++, licence et questions ouvertes
Les projets C++ construisent la bibliothèque statique à partir du code source et lient la cible CMake light_ocr::core. L'API accepte les pixels décodés GRAY8, RGB8, BGR8 ou RGBA8, et le README renvoie au guide API C++ et aux instructions de compilation. Le projet est distribué sous licence Apache License 2.0. Le texte de licence accorde des droits de copie, modification, distribution et utilisation de brevets, mais ne dit rien sur la sécurité, le support ou la garantie. Les métadonnées du dépôt telles que les étoiles et les forks ne sont pas des affirmations de capacité. Le README ne décrit pas les données d'entraînement du modèle, les benchmarks supplémentaires au-delà du rapport de version lié, ni la validation en production ; ces points restent des questions de vérification.
Dans light-ocr, le contrôle 7 prend une forme concrète : `npm install @arcships/light-ocr`. Le fichier de référence et la sortie attendue doivent rester visibles pendant l'essai, car PDFium, PP-OCRv6 Small et coordonnées quadrilatères ne constitue pas une promesse indépendante du contexte. Une lecture attentive des erreurs, des journaux et des artefacts produits permet de distinguer une fonction réellement disponible d'une simple mention dans le README.
Pour une équipe, la question pratique du contrôle 7 est la reproductibilité du chemin light-ocr : quelles dépendances sont locales, quels droits sont requis et quel résultat peut être inspecté sans service tiers ? Cette séparation est utile pour décider si l'outil convient à un poste isolé, à un pipeline automatisé ou à une expérimentation courte. Le dépôt ne documente pas toutes les combinaisons possibles ; les cas non décrits doivent donc rester des hypothèses.
Conclusion éditoriale
light-ocr s'adresse aux personnes qui acceptent d'examiner `npm install @arcships/light-ocr` et les artefacts produits avant une intégration. Il convient moins à un usage qui exige une garantie non documentée ou une dépendance entièrement invisible. Commencez par reproduire ce chemin et observez PDFium, PP-OCRv6 Small et coordonnées quadrilatères dans votre environnement.
Notes de la communauté