Archives par mot-clé : ocr

Numériser la presse : la mise en ligne sur le Kiosque lorrain

La fin des opérations de contrôle des fichiers livrés par le prestataire de numérisation signe le début de la préparation de la mise en ligne (lire billet précédent).

 

Page d'accueil du Kiosque Lorrain
Page d’accueil du Kiosque Lorrain

La préparation des fichiers

Le Kiosque lorrain repose sur des fichiers image au format jpeg et des fichiers XML/ALTO1 (pour le mode texte et le moteur de recherche).

Pour la presse nous avons fait le choix de numériser en jpg non compressé, la numérisation est réalisée en 300 dpi, désormais en couleur. Le format tiff est trop lourd en terme d’archivage, c’est la principale raison de notre choix. Nous nous orientons probablement vers une alternative déjà pratiquée par la BNF, le choix du jpg 2000 (ratio poids qualité plus intéressant).

Quoi qu’il en soit, les formats livrés ne sont pas destinés à la mise en ligne, les fichiers doivent être réduits en taille et optimisés pour assurer une bonne qualité de lecture pour un poids moindre afin de ne pas surcharger le serveur pour garantir des temps de réponse satisfaisants.

Préparation du fichier de chargement

Pour éviter les erreurs sur des fichiers de tableurs très longs, on ne part pas du fichier de récolement que l’on a transmis au prestataire. D’autant que celui-ci a été retourné avec des corrections ou des indications qui correspondent aux problèmes rencontrés au cours de la numérisation (pages signalées dans le fichier mais en fait manquantes, pages oubliées dans le comptage etc.).

Les fichiers pdf, dont on demande également la génération au prestataire, ne sont pas utilisés directement pour la visualisation dans le Kiosque (ils sont proposés pour le téléchargement), ils servent de base au travail de préparation du versement. En effet dans le Kiosque un item correspond à un fascicule de presse (donc à un pdf). On utilise Exiftool pour extraire les métadonnées des fichiers pdf ainsi que le nombre de pages les composant et la racine de leur nom de fichier. Ces informations sont extraites sous forme de fichier csv. Celui-ci sera alors retravaillé pour devenir le fichier source du chargement en masse des fascicules :

  • ajout des métadonnées Dublin Core complémentaires ;
  • concaténation et transformation de certains champs pour les rendre compatibles au format DC ;
  • ajout éventuel de métadonnées.

Les contraintes du plugin Omeka Newspaper

Le plugin développé pour Omeka2 pour le chargement et la mise en ligne de la presse nous impose actuellement un certain nombre de contraintes.

  • nécessité de déclarer le ratio de réduction dans le fichier de chargement : pour que la fonction de surlignage fonctionne, il faut que la position de chaque mot renseigné dans le fichier alto soit recalculée en fonction de la nouvelle taille en pixel de l’image qui sera uploadée sur le Kiosque.
  • nécessité d’un nommage des fichiers rigoureux. Le plugin part du nom de fichier du pdf pour déterminer le chargement des jpg et des alto, ces trois types de fichiers doivent impérativement avoir la même structure pour que l’import fonctionne.
  • les métadonnées : le mapping est basé sur un fichier csv qui va contenir tous les éléments nécessaires d’une part au chargement des différents fichiers, d’autre part à la création de l’item et à sa notice en Dublin Core.

Le chargement sur la base

 

Interface de l'upload des fichiers dans le Kiosque
Interface de l’upload des fichiers dans le Kiosque

Une fois le chargement lancé, le plugin génère un fichier de log qui va contenir les erreurs rencontrées. Elles peuvent être de deux types :

  • les erreurs fatales : le chargement s’interrompt si les champs ne sont pas ceux attendus (format Dublin Core et deux champs techniques, un pour le ratio de réduction, l’autre pour le nombre de vues attendues) ;
  • les erreurs mineures : le chargement continue mais un message d’erreur signale le problème rencontré et indique soit que l’item est incomplet (nombre de pages attendu différent du nombre de jpg présent sur le serveur de chargement) : fichier alto considéré comme vide (ce n’est pas forcément une erreur si l’ocr n’a rien détecté, comme cela peut être le cas sur une page restaurée avec du papier japon opaque par exemple), fichier non chargé pour un problème de nommage.
Interfacede l'historique des imports
Interface de l’historique des imports

Ces logs vont permettre de revenir au cas par cas sur les problèmes rencontrés.

La publication

Une fois les contenus chargés et les corrections effectuées, les fascicules peuvent être rendus publics. Commence alors la phase d’éditorialisation : sélection des contenus en page d’accueil, rédaction de dossiers…


Orientation bibliographique :

  1. Voir article précédent pour en savoir plus sur le format ALTO []
  2. Développé par la société liverdunoise Moobee et disponible sur github. []