HTR · 04

Préparer un environnement de test pour travailler avec HTR

Publié le: Mis à jour le: Éditeur: Vestigia Scriptorium

Introduction

Avant de commencer à créer notre propre Ground Truth et à entraîner le modèle HTR, il est conseillé de préparer un environnement de test séparé dans lequel nous pouvons expérimenter en toute sécurité des documents numérisés, des modèles et des paramètres d'outils individuels.

Il n'est pas nécessaire de construire une infrastructure de serveur ou d'acquérir un poste de travail puissant pour la première expérience. Il est plus important de choisir un environnement qui correspond à l'objectif du projet.

Trois options de base peuvent être distinguées d'un point de vue pratique pour travailler avec des manuscrits historiques :

  1. Transkribus– le moyen le plus simple sans installer notre propre infrastructure HTR ;
  2. eScriptorium– un environnement graphique local ou basé sur un serveur utilisant, entre autres, le système Kraken ;
  3. Kraken– un outil distinct contrôlé principalement à partir de la ligne de commande.

Chaque variante est adaptée à une manière différente de travailler.


1. Déterminez d'abord le but de l'environnement de test

Avant d'installer un logiciel, il est conseillé de répondre à quelques questions de base.

Nous voulons uniquement :

  • essayez la reconnaissance automatique de plusieurs pages ;
  • créez votre propre Ground Truth ;
  • entraînez votre propre modèle ;
  • expérimentez différents modèles ;
  • traite les documents localement sans les envoyer à un service externe;
  • automatise le traitement de centaines ou de milliers d'images;
  • connecter HTR à votre propre programme ou environnement de base de données ?

Si nous voulons simplement comprendre le principe de travail avec HTR, notre propre serveur est une complication inutile.

Cependant, si nous souhaitons expérimenter les formats de données, l'automatisation, les modèles personnalisés et le traitement par lots, l'environnement local commence à prendre du sens.


Option A : Transkribus - le moyen le plus simple

2. Quand utiliser Transkribus

Pour un débutant, Transkribus est généralement le chemin le plus rapide vers la première expérience.

Pas besoin d'installer Python, une base de données, Docker ou un framework de réseau neuronal. L'utilisateur crée un compte, télécharge des documents et travaille via l'application Web.

Transkribus permet par exemple :

  • importer des documents numérisés ;
  • Analyse automatique de la disposition;
  • création et correction de transcriptions ;
  • préparation de Ground Truth;
  • Utilisation de des modèles HTR existants ;
  • formation propres modèles ;
  • évaluation des résultats ;
  • exporte les transcriptions.

Pour la première introduction à HTR, il convient donc de commencer ici.

Ce dont nous avons besoin

Le minimum pratique consiste en :

  • Ordinateur ordinaire;
  • Navigateur Web moderne;
  • Connexion Internet;
  • un compte Transkribus ;
  • plusieurs pages numérisées de haute qualité d'un document historique.

Il n'est pas nécessaire d'effectuer les calculs eux-mêmes sur votre propre ordinateur.

Ce qui ne convient plus à l'installation

Il existait auparavant un client eXpert Transkribus de bureau. Cependant, il est désormais répertorié comme obsolète et n’est pas développé davantage; les nouvelles fonctions sont concentrées dans l'application web. [1]

Cela n'a donc aucun sens de créer un workflow sur un client de bureau pour un nouveau projet.


Variante B : eScriptorium – propre environnement graphique HTR

3. Qu'est-ce que eScriptorium

eScriptorium est un environnement ouvert conçu pour travailler avec des documents historiques. Il fournit une interface Web pour l'importation d'images, la segmentation, la transcription, l'annotation, l’entraînement de modèles et la reconnaissance automatique.

Pour le HTR lui-même, il utilise principalement le système Kraken. [2]

L'avantage du eScriptorium réside dans la combinaison de deux fonctionnalités :

  • L'utilisateur travaille dans une interface Web graphique ;
  • l'environnement lui-même peut être exécuté sur votre propre ordinateur ou serveur.

Cela convient, par exemple, lorsque nous voulons avoir des données d'image, Ground Truth et des modèles sous notre propre contrôle.


4. Environnement recommandé pour la première installation locale

Le moyen le plus simple d'accéder à un eScriptorium local est actuellement Docker.

La documentation officielle eScriptorium répertorie Docker comme méthode d'installation recommandée. [3]

Par exemple, la configuration suivante convient à un ordinateur de test :

Système d'exploitation

  • Linux ;
  • macOS ;
  • Windows avec WSL 2.

Pour les expériences techniques, Linux est généralement le plus pratique, comme la version LTS actuelle d'Ubuntu.

Logiciel de base

Nous avons besoin de :

  • Git ;
  • Moteur Docker ou ordinateur de bureau Docker ;
  • Docker Compose v2 ;
  • Navigateur Web.

Docker résout ici un problème important : eScriptorium n'est pas un programme unique, mais un ensemble de plusieurs services. Il utilise une application Web, une base de données PostgreSQL, des travailleurs Redis et Celery, entre autres. Docker exécute des composants individuels dans des conteneurs distincts. [2]

Pour un débutant, c'est beaucoup plus simple que d'installer toutes les dépendances séparément.


5. Contrôle Docker

Après avoir installé Docker, nous vérifierons d'abord qu'il fonctionne.

Dans le terminal :

docker --version
docker compose version

La deuxième commande est importante. La documentation actuelle eScriptorium utilise la commande :

docker compose

, c'est-à-dire Docker Compose v2.

Ancien programme autonome :

docker-compose

est déjà obsolète. [3]

Nous pouvons vérifier la fonctionnalité de Docker par exemple :

docker run hello-world

Si le conteneur de test démarre correctement, l'environnement de base est prêt.


6. Télécharger eScriptorium

Nous allons télécharger les fichiers sources en utilisant Git :

git clone https://gitlab.com/scripta/escriptorium.git
cd escriptorium

Ensuite nous créons un fichier de configuration :

cp variables.env_example variables.env

Le fichier variables.env contient les paramètres d'instance locale.

Avant le premier run, il est conseillé de modifier au minimum :

  • SECRET_KEY;
  • Nom de l'administrateur;
  • Mot de passe administrateur;
  • Courriel de l'administrateur;
  • éventuellement paramètres de domaine et de réseau.

Même dans l'environnement de test, il n'est pas conseillé de conserver le mot de passe par défaut si le système est accessible depuis une autre partie du réseau. [3]


7. Démarrage de eScriptorium

Les images de conteneur actuelles peuvent être téléchargées avec la commande :

docker compose pull

Ensuite, nous démarrons l'environnement :

docker compose up -d

Le paramètre -d signifie que les conteneurs s'exécuteront en arrière-plan.

Nous vérifierons le statut :

docker compose ps

Par défaut, l'interface locale est disponible dans le navigateur à l'adresse :

http://localhost:8080/

Nous nous connectons avec le compte administrateur défini dans variables.env. [3]


8. Comment arrêter eScriptorium

Nous pouvons arrêter l'environnement de test :

docker compose down

Les données sont conservées.

Soyez très prudent avec la commande :

docker compose down -v

L'option -v supprime également les volumes Docker, afin de pouvoir supprimer la base de données et les données d'instance stockées. [3]

Il est donc plus sûr pour un débutant d'utiliser les communs :

docker compose down

Variante C : Kraken - fonctionne directement avec le moteur HTR

9. Qu'est-ce que Kraken

Kraken est un système open source de reconnaissance automatique de texte, axé principalement sur les documents historiques et divers types d'écritures.

Il prend en charge, entre autres :

  • Segmentation de pages;
  • Détection de ligne;
  • Reconnaissance de texte;
  • entraînement de modèles personnalisés;
  • PAGE XML;
  • ALTO ;
  • hOCR;
  • fonctionne avec des modèles pré-entraînés. [4]

Il est particulièrement adapté aux utilisateurs qui souhaitent contrôler les différentes étapes du processus HTR ou les incorporer dans leurs propres scripts.


10. Création d'un environnement Python isolé

Kraken ne doit pas être installé sans discernement dans le système Python.

Pour les travaux expérimentaux, il est préférable de créer un environnement virtuel séparé.

Par exemple :

python3 -m venv htr-env

Activation sous Linux et macOS :

source htr-env/bin/activate

Ensuite, nous mettons à jour les installateurs :

python -m pip install --upgrade pip

et installez Kraken :

pip install kraken

La documentation actuelle de Kraken répertorie l'installation via pip comme chemin standard pris en charge. [4]


11. Vérification de l'installation Kraken

Après l'installation :

kraken --help

Si l'aide s'affiche, l'installation de base fonctionne.

Kraken a également accès à un référentiel de modèles existants. Les modèles disponibles peuvent être consultés par exemple :

kraken list

Des informations sur un modèle spécifique peuvent être obtenues en utilisant :

kraken show IDENTIFIKATOR_MODELU

Kraken vous permet ainsi d'expérimenter non seulement avec vos propres modèles, mais également avec des modèles existants disponibles gratuitement. [4]


12. Premier test de reconnaissance

Avant de former votre propre modèle, il est conseillé de vérifier l'intégralité du pipeline de traitement sur une seule image.

Le principe de traitement est le suivant :

image → segmentation → reconnaissance → texte/XML

Avec un modèle adapté, vous pouvez utiliser par exemple :

kraken -i strana.tif vystup.txt segment -bl ocr -m model.mlmodel

Kraken détermine d'abord la structure de ligne, puis effectue la reconnaissance à l'aide du modèle spécifié. [4]

Le but de cette première expérience n’est pas d’obtenir une transcription parfaite.

Il nous suffit de vérifier que :

  • Le Kraken peut être lancé ;
  • L'image d'entrée peut être chargée ;
  • Le modèle peut être chargé ;
  • Une segmentation se produira ;
  • Le texte de sortie sera généré.

Ce n'est qu'à ce moment-là qu'il est judicieux de vous lancer dans votre propre formation.


13. Processeur ou GPU ?

L'une des questions les plus courantes lors de la création d'un environnement HTR est de savoir si une carte graphique est requise.

Uniquement pour les tâches suivantes :

  • Visualisation de documents;
  • préparation de Ground Truth;
  • correction des transcriptions;
  • petits tests de reconnaissance ;

Un GPU puissant n'est pas une condition préalable.

Cependant, lors de l'entraînement de modèles neuronaux, un GPU compatible peut considérablement accélérer le processus.

eScriptorium permet au formateur d'utiliser les GPU NVIDIA via NVIDIA Container Toolkit. La documentation actuelle utilise une configuration de périphérique du type :

KRAKEN_TRAINING_DEVICE=cuda:0

et configuration GPU dans Docker Compose. [3]

Pour la première expérience, cependant, il n'est pas conseillé de commencer par installer CUDA et les pilotes s'il n'est pas certain que nous en aurons besoin.

Une ligne de conduite plus judicieuse est la suivante :

exécutez d'abord le système sur le processeur → créez une petite expérience → puis configurez un GPU.

Cela réduira considérablement le nombre de sources possibles de problèmes d'installation.


14. Structure recommandée des répertoires de projets

Quel que soit l'outil que vous choisissez, il est utile d'organiser vos données dès le départ.

Par exemple :

htr-projekt/
│
├── images-ouiginal/
│   └── images numérisées ouiginales
│
├── images-wouking/
│   └── copies de travail des images
│
├── ground-truth/
│   └── transcriptions vérifiées
│
├── pagexml/
│   └── PAGE XML
│
├── models/
│   ├── model-001/
│   ├── model-002/
│   └── model-003/
│
├── test/
│   └── données de test indépendantes
│
├── results/
│   └── résultats des expériences
│
└── documentation/
    ├── transcription-rules.md
    └── experiment-log.md

Une telle division ne constitue pas une condition technique du système HTR. C’est une mesure organisationnelle qui va commencer à porter ses fruits très rapidement.

Il est particulièrement important de séparer :

images originales,
Ground Truth,
données d'entraînement,
données de test indépendantes,
résultats de modèles individuels.

Sinon, il peut facilement arriver plus tard que nous ne sachions pas si une certaine page faisait ou non partie de l’entraînement.


15. Ne modifiez pas les images originales

Il est conseillé de conserver les fichiers numérisés originaux dans un répertoire séparé et de ne pas les écraser.

Si nous devons changer :

  • Résolution;
  • Contraste;
  • Couleur;
  • recadrage;
  • Binarisation;
  • Orientation de l'image;

, nous créerons une copie de travail.

Le fichier original doit être conservé.

Ceci est important non seulement pour l’expérience HTR, mais également pour la reproductibilité archivistique générale du traitement.


16. PAGE XML comme format d'échange approprié

Pour un travail à plus long terme, il n'est pas conseillé de verrouiller le projet uniquement sur le format interne d'un programme.

L'un des formats les plus utilisés pour les documents historiques est PAGE XML.

Il peut contenir par exemple :

  • Dimensions des pages;
  • Zones de texte;
  • coordonnées des lignes;
  • lignes de base;
  • Ordre de lecture;
  • Transcription;
  • informations structurelles supplémentaires.

Kraken prend en charge PAGE XML et l'écosystème OCR-D utilise également PAGE XML comme format Ground Truth majeur. [4] [5]

Pour un projet d'archivage, il convient donc de vérifier que Ground Truth et les résultats peuvent être exportés dans un format standardisé indépendant d'une application spécifique.


17. Tenir un registre des expériences

Une situation se présente très facilement :

« Le modèle numéro 7 était meilleur que le modèle numéro 6, mais nous ne savons plus pourquoi. »

Il est donc conseillé de conserver un protocole simple dès la première expérience.

Par exemple :

Model: statek-001
Date : 2026-09-09

Training:
45 pages
8 742 mots

Validation:
5 pages
963 mots

Base model:
nom / identifiant

Paramètres :
...

CER validation:
7,4 %

Remarque :
Problèmes avec le scribe C.
Confond souvent r/n et e/c.

Version suivante :

Model: statek-002

Modification :
+15 pages GT du scribe C

CER validation:
5,8 %

Un tel fichier texte brut peut être plus précieux ultérieurement que les journaux de sauvegarde automatique eux-mêmes.


18. Gestion des versions

Git convient aux fichiers de configuration, aux règles de transcription, aux scripts et à la documentation.

Par exemple :

git init

Cependant, nous n'avons pas besoin de stocker des milliers de grandes images TIFF ou des modèles de plusieurs gigaoctets dans Git.

Git est particulièrement adapté pour :

  • Règles de transcription;
  • Scripts;
  • Fichiers de configuration;
  • petits fichiers XML ;
  • Documentation des expériences.

Il est préférable d'archiver les données d'images volumineuses d'une autre manière.


19. Sauvegarde

Ground Truth est généralement plus cher que le modèle HTR lui-même.

Nous pouvons entraîner à nouveau le modèle.

Une transcription créée et vérifiée manuellement de centaines ou de milliers de lignes peut représenter des dizaines, voire des centaines d'heures de travail humain.

Par conséquent, Ground Truth doit être régulièrement sauvegardé sur au moins deux copies indépendantes.

Une hiérarchie pratique de valeurs de données a tendance à être :

image numérisée originale → Ground Truth → métadonnées et documentation → modèle → sortie générée automatiquement

Perdre un modèle est ennuyeux.

La perte de qualité Ground Truth peut signifier devoir refaire une partie substantielle de l'ensemble du projet.


20. Environnement de test recommandé pour un débutant

Deux phases peuvent être recommandées pour la première expérience.

Phase 1 - aucune installation

Nous utiliserons :

Transkribus + 10 à 20 pages d'un document

L’objectif est de comprendre :

  • Segmentation;
  • lignes de base;
  • Transcription;
  • Ground Truth;
  • Modèles existants;
  • CER;
  • Principe d’entraînement.

Ce n'est que si nous découvrons que nous souhaitons utiliser systématiquement HTR que nous passerons à un environnement local.

Phase 2 - Laboratoire local

Sur un ordinateur ordinaire, nous préparerons :

Windows + WSL 2
ou
Linux

+
Git
+
Docker
+
eScriptouium
+
Kraken
+
source code editou
+
Git repositouy fou configuration and documentation

Cela nous donne un environnement dans lequel nous pouvons expérimenter à la fois via l'interface graphique eScriptorium et directement avec Kraken.


21. Première expérience technique recommandée

Il n'est pas conseillé de télécharger immédiatement un volume d'archives de 300 pages après l'installation.

Par exemple, cinq à dix pages suffisent.

Procédure :

1. Copiez les images dans le répertoire de travail.

2. Importez-les dans eScriptorium ou Transkribus.

3. Effectuer la segmentation.

4. Vérifiez les lignes de base.

5. Essayez un modèle HTR existant.

6. Corrigez manuellement plusieurs pages.

7. Exporter Ground Truth.

8. Vérifiez que nous pouvons recharger Ground Truth.

9. Si nous utilisons Kraken, exécutez la reconnaissance d'image unique à partir de la ligne de commande.

10. Enregistrez le logiciel utilisé, le modèle et le résultat obtenu.

Ce n'est que lorsque cette petite boucle fonctionnera du début à la fin que nous étendrons l'expérience à des dizaines de pages.


22. Que choisirais-je pour mon propre projet d'archives

Si l'objectif est principalement de traiter des documents historiques, et non d'étudier la gestion des serveurs, je commencerais par Transkribus.

S’il s’avère que nous avons besoin de :

  • contrôle total sur les données ;
  • Traitement local;
  • Automatisation personnalisée;
  • expérimente des modèles ouverts ;
  • Connexion à un logiciel personnalisé ;

Je construirais alors un deuxième environnement de test basé sur :

Docker + eScriptorium + Kraken.

J'utiliserais une installation distincte de Kraken principalement pour les expériences, les scripts automatisés et le travail plus détaillé avec les modèles.

Cela créera trois niveaux :

Transkribus
│
│  utilisation la plus simple
│
eScriptouium
│
│  environnement propre + interface graphique
│
Kraken
│
│  command line and direct wouk with HTR
│
own scripts and data woukflows

Pour les expériences d'enseignement et d'archivage, un tel arrangement est plus pratique que d'essayer de créer une infrastructure HTR personnalisée complète dès le premier jour.


Notes et sources utilisées

[1]LECTURE-COOP. How to use Transkribus eXpert (deprecated). Documentation Transkribus. Le client de bureau eXpert Transkribus n'est plus mis à jour et les nouvelles fonctionnalités sont acheminées vers l'application Web.
https://help.transkribus.org/downloading-and-installing-transkribus-expert-deprecated

[2]Scripta. eScriptorium. Dépôt source et description de l'architecture du projet. eScriptorium intègre des outils de transcription, d'annotation, d’entraînement et de reconnaissance de documents historiques et utilise Kraken.
https://gitlab.com/scripta/escriptorium

[3]Scripta. eScriptorium – Install with Docker. Documentation d'installation actuelle. Il recommande Docker, Docker Compose v2 et décrit également la configuration du GPU à l'aide de NVIDIA Container Toolkit.
https://gitlab.com/scripta/escriptorium/-/wikis/docker-install

[4]KIESSLING, Benjamin. Kraken 5.3 Documentation. Documentation de l'installation, de la segmentation, de la reconnaissance, des modèles et des formats de sortie pris en charge.
https://kraken.re/5.3.0/

[5]OCR-D. The Ground Truth Guidelines. Documentation Ground Truth et PAGE XML.
https://ocr-d.de/en/gt-guidelines/trans/

[6]OCR-D. OCR-D Quick Start Guide. Un exemple de préparation d'un environnement de conteneur à l'aide de Docker et d'utilisation de documents historiques.
https://ocr-d.de/en/start