Transformer son Omeka S en service IIIF ?

Pour exposer des ressources internes via le protocole IIIF, il est recommandé de satisfaire aux préconisations des deux principales API IIIF : l’API Image et l’API Présentation.

Exposer ses médias avec l’API Image

Il s’agit de pouvoir délivrer des images manipulables par des clients externes. Pour cela, elles doivent être préparées en amont (génération statique) ou servies directement (génération dynamique ou « à la volée ») par un dispositif spécifique qui générera également le fichier d’information de l’image (info.json) et l’URL correspondante. Dans ce cas, trois solutions s’offrent à vous :

• Utilisation d’un service externe qui s’occupe d’exposer les images en IIIF. C’est le cas par exemple de l’entrepôt de données Nakala (voir le cas d’usage Nakala). Il existe aussi des services commerciaux : Micrio, IIIFHosting, Teklia, etc.
• Ajout d’un module spécifique sur l’instance Omeka S qui va faire office de serveur d’images. C’est ce que propose le module Image Server (Voir plus bas).
• Installation autonome d’un logiciel dédié, dit « serveur d’images », que l’on va coupler à l’instance Omeka S. Dans ce cas, il faut avoir certaines compétences et ressources informatiques comme l’accès à une machine virtuelle (qui peut être la même que celle de l’instance Omeka S, ou non).

Le choix entre ces différentes options dépend totalement de votre infrastructure, de la typologie de vos documents et médias, des ressources et compétences dont vous disposez. Pour une bibliothèque virtuelle basée sur Omeka S, l’utilisation d’un serveur d’images IIIF externe plutôt qu’un serveur interne reposant sur des modules Omeka S présente plusieurs avantages :

• Un serveur d’images externe est spécialement conçu pour le traitement et la diffusion d’images en respectant au mieux l’API Image de IIIF. Il offre de bonnes performances et fournit des fonctionnalités avancées.
• Il permet d’optimiser les ressources allouées par rapport aux besoins : il peut être dimensionné indépendamment de l’installation Omeka S et s’adapter aux évolutions des volumes et des demandes.
• Cette architecture sépare les responsabilités : d’une part, la gestion des métadonnées et l’exposition des données avec Omeka S, et d’autre part, l’administration du service et le traitement des images via un serveur d’images IIIF dédié. Cette approche facilite aussi le partage des images avec d’autres applications ou institutions.

Le recours au module Image Server d’Omeka S est plus simple à configurer et est suffisant pour des collections modestes. Cependant, pour des projets plus importants ou nécessitant des performances optimales, un serveur d’images IIIF dédié représente une solution plus robuste.

Cantaloupe et IIPImage sont les serveurs d’images les plus utilisés ; ce sont des logiciels libres. Les premiers pas avec un serveur d’images externe sont abordés dans la partie Utiliser un serveur d’images IIIF autonome – Cantaloupe.

Module Image Server

Le module Image Server, développé et maintenu par Daniel Berthereau, simule un serveur d’images interne à l’instance Omeka S quand on ne dispose pas de serveur d’images en propre (comme Cantaloupe). Il n’est donc pas utile de l’implémenter si on utilise déjà un serveur d’images externe.

Une fois les modules Common et IIIF Server installés, vous pouvez passer à l’installation du module Image Server.

Image Server dote Omeka d’un serveur d’images IIIF. Les spécifications complètes de l’API Image sont prises en charge (versions 2 et 3). Pour des besoins standards vous pouvez laisser cochées les cases Image Api 2 niveau 2 et Image API 3 niveau 2 dans le formulaire de paramétrage du module.

Pour permettre les fonctionnalités de zoom proposées par IIIF, Image Server extrait des tuiles par niveau de zoom à partir des images originales liées aux ressourcs. Il stocke les tuiles à part dans le répertoire files/tile de l’installation d’Omeka S. Ces tuiles seront appelées par la visionneuse pour afficher l’image. C’est ce que l’on nomme un tuilage statique. On peut suivre et garder le paramétrage par défaut proposé dans la section Service de tuilage.

Au moins un processeur d’image, qui se charge de découper les images en tuiles, doit être installé sur le serveur qui héberge votre Omeka S. Quatre options sont possibles dans les paramétrages du module. Elles sont rangées par ordre décroissant de rapidité pour cette opération : Vips, GD (extension PHP), Imagick (extension PHP), ImageMagick. Si aucun de ses logiciels n’a été installé lors de l’installation de votre Omeka S par votre équipe informatique, il vous sera nécessaire de revenir vers eux pour en faire la demande. En l’absence de renseignement clair sur la question, la case par défaut Automatic : Vips when possible, else GD, else Imagick, else ImageMagick convient pour le fonctionnement du module.

Le format de tuilage indique le format sélectionné pour générer les tuiles par le processeur d’image sélectionné en amont (ImageMagick, Vips, etc.).

DeepZoom est sélectionné par défaut et est recommandé pour la plupart des usages. Les tests effectués montrent qu’il est pour le moment le plus performant des formats de tuiles proposés par le module Image Server.

Pour aller plus loin, vous pouvez consulter l’annexe qui est dédiée à la configuration d’Image Server et aux processus de tuilage.

Exposer ses ressources avec l’API Présentation

Deux modules ont pour objectif de générer des Manifestes IIIF à partir des métadonnées descriptives et des médias de chaque Contenu :

• IIIF Presentation
• IIIF Server

Les deux modules suivent la syntaxe définie par l’API IIIF Présentation, qui a actuellement 2 versions en activité. Ils entendent prendre en charge les deux versions. Dans les faits, ils créent donc 2 Manifestes pour chaque Contenu : un pour l’API Présentation 2, et un pour l’API Présentation 3.

Les deux modules forgent des Manifestes présentant les informations essentielles à la contextualisation d’un Contenu : titre et autres métadonnées descriptives, attribution, licence d’utilisation, mention de l’API Omeka S qui a permis leur récupération, et - plus accessoirement - sens de lecture des médias. Ils signalent aussi les collections Omeka ainsi que les Collections IIIF auxquelles le Manifeste peut appartenir.

Les deux modules affichent de manière complète la liste de tous les Canevas (c’est-à-dire les “vues” d’un document numérisé) compris dans le document, avec, pour chacun, l’URI de chaque image fourni par l’API Image. Les Manifestes intègrent également les potentielles Annotations qui ont pu y être jointes. Chaque Manifeste dispose aussi de sa miniature image (thumbnail).

Les versions API Présentation 2 et API Présentation 3 n’utilisent pas exactement la même syntaxe, mais dans tous les cas ces informations figurent.

Module IIIF Presentation

Ce module est produit par Omeka Team, concepteurs d’Omeka S, qui en assure également la maintenance. Il permet d’obtenir des Manifestes IIIF contenant les informations détaillées ci-dessus. Il n’est pas paramétrable depuis le tableau de bord de votre installation. Il diffuse par défaut des Manifestes utilisant la version 3 de l’API Présentation.

Module IIIF Server

Ce module est développé par Daniel Berthereau. Il était initialement fusionné avec Image Server, ce qui se traduit aujourd’hui par leur dépendance mutuelle. Il offre de plus larges possibilités de personnalisation que IIIF Presentation, pourvu que l’on s’approprie son tableau de configuration pour le moins foisonnant.

La configuration par défaut du module est fonctionnelle. Aucune modification n’est requise pour afficher les images et les métadonnées qui leur sont associées. Il est néanmoins utile de tester le bon fonctionnement de cette configuration par défaut avant de commencer à la personnaliser.

⚠ Avant d’effectuer ce test, si ce n’est pas déjà fait, il vous faut finaliser et tester l’installation du module Image Server.

Détail de la procédure test

Ce test peut s’effectuer dans un premier temps sur l’URL d’un Manifeste IIIF, dont la syntaxe proposée par IIIF Server est de type :

{scheme}://{server_url}/iiif/{api_presentation_version}/{item_id}/manifest => exemple: https://bina.bulac.fr/iiif/2/406292/manifest

Entré en barre de recherche, cet URL doit charger l’entièreté du Manifeste au format JSON, comme sur cet exemple :

Une fois cette première étape passée, vous pouvez vérifier que le Manifeste est utilisable par Omeka S en l’enregistrant comme média pour un Contenu, afin qu’il puisse être visualisé :

Dans la fenêtre d’édition d’un item dans l’interface admin d’Omeka S :

1. Rendez vous dans l’onglet Media
2. Cliquez sur ajouter un media IIIF Presentation
3. Renseignez l’URL du Manifeste que vous avez testé au préalable
4. Sauvegardez les modifications

Le Contenu test donnera à voir l’entièreté des images fournies par le Manifeste IIIF, dans une fenêtre Mirador qu’Omeka S propose par défaut depuis ses versions 4.0.0.

Particularités du module IIIF Server

Le module fournit des Manifestes IIIF plus détaillés que ceux du module IIIF Presentation, notamment sur les points suivants :

• Mention de tous les médias importés dans le Contenu source, et disponibles au téléchargement, dans la section “rendering” ;
• Intégration d’un formulaire de requête pour l’API IIIF Content Search et lecture de fichiers de transcription texte (voir le point dédié à la recherche en texte intégral) ;
• Utilisation d’un identifiant pérenne dans l’URI du Manifeste (ARK, DOI…), intégré dans Omeka S au préalable au moyen du module Clean Url (attention, cette fonctionnalité n’est toutefois pas encore complètement étendue aux Manifestes IIIF intégrant de la transcription texte)

Configurer IIIF Server

Le module est entièrement configurable, et la pléthore d’options peut être déroutante. Nous listons ici les plus importantes, par ordre d’affichage dans le menu :

• En-têtes CORS : elles sont essentielles à la transmission du Manifeste IIIF au navigateur des usagers. La case est cochée par défaut. Néanmoins, si vos gestionnaires informatiques ont déjà paramétré l’ajout de ces en-têtes au niveau du serveur de votre installation, cela aura pour effet de les rendre inopérants. Rapprochez-vous donc de votre équipe informatique en cas de message d’erreur concernant un “strict-origin-when-cross-origin”

• Cache : par défaut, IIIF Server créé chaque Manifeste à la volée, en interrogeant l’API IIIF Image et l’API Omeka à chaque requête sur un Contenu. Mais si le Manifeste est particulièrement long, parce que le document initial comporte beaucoup de pages et/ou beaucoup de métadonnées descriptives, il peut être avantageux de cocher la case “Cacher les manifestes pour un accès instantané”. Dans ces conditions, IIIF Server écrit le Manifeste IIIF lorsque le Contenu est enregistré dans Omeka dans la mémoire cache du serveur de l’installation, pour qu’il puisse être remis à disposition très rapidement.

• Ce Manifeste en cache se met à jour de lui-même lorsque le Contenu est modifié ; néanmoins, ce n’est pas le cas lorsque les paramétrages du module IIIF Server sont modifiés. Il est alors nécessaire de lancer une tâche de mise à jour du cache, à la toute fin du tableau de configuration. Par défaut, le module met à jour l’ensemble des Manifestes IIIF du cache.

• Licence d’exploitation : dans le bloc ci-dessous, il convient soit de renseigner la propriété utilisée pour la licence par les Contenus (choix fait dans cet exemple), soit de renseigner l’URI de la licence choisie deux champs plus bas. Les champs non utilisés peuvent rester vides.

Les principales visionneuses IIIF

Par défaut, Omeka S comporte bien une visionneuse dédiée aux médias susceptible de prendre les traits d’une fenêtre Mirador en présence de Manifestes ou d’OpenSeadragon en présence d’images IIIF. Toutefois, ces visionneuses demeurent limitées dans leurs fonctionnalités et leur personnalisation.

Disposer d’une meilleure marge de manœuvre passe par l’installation de modules. Actuellement, 4 modules proposent la visualisation de ressources IIIF : Universal Viewer, Mirador Viewer, Diva Viewer et Octopus Viewer.

Universal Viewer

Le module Universal Viewer adapte pour Omeka le projet du même nom. Comme son nom l’indique, Universal Viewer se veut une visionneuse universelle capable de prendre en charge une grande variété de formats.

• Elle peut prendre notamment en charge les médias hébergés sur un serveur IIIF (y compris ceux au format pdf et ePub) et les URL de vidéos YouTube.
• Le téléchargement des médias est possible, tant qu’il s’effectue vue par vue: tous les médias associés à une vue (un Canevas) dans tous leurs formats, sont accessibles depuis une icône dédiée. Mais le téléchargement groupé de l’ensemble des médias d’un Contenu n’est pas envisageable.
• Le module installe par défaut une version épurée de la visionneuse (dite “vanilla”), que l’on peut souhaiter compléter par les différents plugins créés par les contributeurs du projet. La marche à suivre est détaillée dans la documentation du module ; elle requiert néanmoins d’être familier des opérations d’administration système (navigation dans le système et gestion de fichiers par ligne de commande, installation de librairies). Ces plugins concernent au moins le traitement de l’OCR dans la visionneuse et l’ajout d’une barre de recherche en texte intégral.
• Par défaut, le module est limité aux formats mp3 et ogg pour l’audio , et webm et ogv pour la vidéo. Toutefois, la visionneuse a été initialement conçue pour supporter une plus grande variété de formats, notamment mp4, wav et mpeg ; ces options peuvent être activées dans le code du module.
• Contrairement aux deux autres visionneuses suivantes, Universal Viewer ne permet pas de charger un Manifeste IIIF externe par son URL d’accès, et n’affiche pas les éventuelles annotations, ou indexation des médias.
• Le développement du module est actif. Après quelques temps sans évolutions, le projet Universal Viewer a été repris à la fin de l’année 2024, et la version 4.1.0 est en production ; le module a été mis à jour par Daniel Berthereau pour l’implémenter en mai 2025.

Mirador Viewer

Le module Mirador Viewer fournit une visionneuse Mirador conçue comme un espace de travail à part entière pour l’utilisateur.

• Premièrement, elle permet aux utilisateurs d’appeler n’importe quels Manifestes IIIF de leur choix via son bouton +, qui a pour effet de scinder la fenêtre en deux, et attribuer à chaque Manifeste un espace de visualisation.
• Elle permet d’implémenter cinq plugins développés par les contributeurs du projet Mirador général, moyennant là encore l’exécution d’une série de commandes données en documentation :
• Annotations : ce plugin permet non seulement l’aperçu des annotations provenant du manifeste IIIf dans le volet latéral dédié aux informations descriptives, mais aussi l’ajout manuel de nouvelles annotations dont le graphisme put être personnalisé (formes, remplissages, contenu texte). À noter que ces nouvelles annotations ne sont pas exportées dans le manifeste IIIF ; elles restent circonscrites à la visionneuse.
• Image tools : ce plugin permet d’effectuer quelques petites modifications sur les médias de type image, par exemple sur leur couleur, leur luminosité ou leur orientation ;
• Download : Téléchargement dans les mêmes conditions qu’Universal Viewer : vue par vue
• Share : copie simplement l’URL du manifeste IIIF ;
• Text Overlay : plugin complexe proposant de visualiser la couche texte d’une ressource image (OCR/HTR), dans un volet latéral séparé et directement en surbrillance sur l’image. Le texte ainsi affiché peut être sélectionné au curseur et entré en barre de recherche. Pour fonctionner correctement, ce plugin nécessite que les fichiers xml-alto aient été importés avec les autres médias, et que leur contenu textuel ait été intégré au manifeste IIIF en tant qu’annotation (ce que propose le module IIIF Server).
• Rappelons qu’en termes de médias, Mirador Viewer n’accepte que ceux qui proviennent d’un serveur IIIF, et ce sans les pdf et les ePub ; si les médias importés sont en pdf, la visionneuse ne les affichera pas, manifeste IIIF ou non. Mais il n’y a pas de limitation sur les formats image ou vidéo hors de celles imposées par Omeka.
• Le module Mirador Viewer fournit également d’autres paramètres personnalisables, comme l’import/export d’un thème personnalisé pour sa fenêtre. Cette option n’est pas toujours fonctionnelle sur Omeka.
• Il peut résulter de cette offre pléthorique une certaine opacification de la visionneuse : son espace se sature d’icônes cliquables, dont la fonction n’est pas d’emblée évidente. Le module Mirador Viewer est également l’un des plus complexes et longs à installer sur Omeka.
• Le développement général du projet Mirador est actif et continu. La dernière version (3.4.3) est sortie en janvier 2025. Le développement du module Mirador Viewer pour Omeka est assuré par Daniel Berthereau, et est mis à jour environ une fois par an.

Octopus Viewer

Octopus Viewer se présente comme une méta - visionneuse spécifiquement développée pour Omeka S et susceptible de s’adapter au type de média en présence.

• Par défaut, un volet latéral liste les médias, et un autre les métadonnées qui y sont rattachées (à ces médias seuls, et non l’entièreté du Contenu). Lorsque l’utilisateur sélectionne un média, si celui est de type pdf ou un manifeste IIIF importé, Octopus Viewer appelle une autre visionneuse à l’intérieur de sa propre fenêtre. Dans le cas de IIIF, cette autre visionneuse est une version standard de Mirador. La fenêtre complète de Mirador est encapsulée dans celle d’Octopus Viewer.
• Néanmoins, le module n’a pas recours aux plugins détaillés plus haut : il en résulte que les Annotations IIIF peuvent être montrées, mais non créées sur place ; qu’il n’y aura pas d’outils de retouche d’image ; qu’il n’y aura pas de visualisation à part ou en surbrillance de l’OCR ; et pas de téléchargement direct, ou de copie de l’URL du manifeste IIIF. L’option de téléchargement est possible depuis la fenêtre d’Octopus Viewer, média par média.
• Mais la possibilité de charger un manifeste IIIF extérieur reste la même - si la perspective de fenêtres encapsulées les unes dans les autres à plus de deux niveaux ne cause pas de vertige.
• Il est recommandé d’importer le manifeste IIIF en tête des médias de chaque Contenu : Octopus Viewer ne parcourt pas les médias de lui-même, et n’affiche pas l’icône IIIF par défaut. Dans le cas d’une longue liste de médias, l’utilisateur pourrait ignorer qu’une visualisation par IIIF est possible.
• Le module prend au moins les formats jpeg, jp2, png, tiff, webp, pdf et mp4 en charge.
• Le développement d’Octopus Viewer est assuré par l’entreprise BibLibre ; créé il y a deux ans seulement, des évolutions importantes de ses fonctionnalités sont sans doute à attendre.

Diva Viewer

Diva Viewer est une adaptation de la visionneuse Diva par Daniel Berthereau.

• Ce module se distingue par son recours à la technologie Ajax, dont le but est d’afficher directement les médias image en résolution maximale. La fenêtre de visualisation est donc prédominante sur la page du Contenu.
• Les métadonnées descriptives et options de téléchargement sont masquées derrière de petites icônes discrètes. Diva propose elle aussi des options de retouche d’image minimale, comme le plugin Image tools de Mirador Viewer.
• Initialement dédiée à la visualisation d’images classiques, son extension au protocole IIIF reste limité ; elle ne propose pas de visualisation des annotations, ni de chargement de manifeste IIIF externe.

Tableau de synthèse