Annexe 1 – Omeka S ImageServer et les tuiles
La présente annexe mélange des données théoriques ainsi que des résultats de tests pour affiner la compréhension du module Image Server.
Que fait le module Image Server ?
Le module Image server effectue deux opérations liées mais
distinctes: 1) Il implémente l’API Image IIIF, au sens où il
sait répondre aux requêtes du
type : * modèle
d’URL:
{scheme}://{server{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}
* exemple :
https://api.nakala.fr/iiif/10.34847/nkl.8e31p9d2/014f975b5550100f7a5b977ae409d4c51f3ae263/full/full/0/default.jpg
- Il effectue des traitements sur les images pour optimiser ou transformer les images qu’il envoie lorsqu’il répond à une requête API Image IIIF. Parmi ces traitements, un des plus importants est le tuilage.
Qu’est ce que l’opération de tuilage ?
Le tuilage consiste à découper une image de grande taille en de plus petites images (appelées tuiles) qui seront affichées uniquement lorsque le niveau de zoom requis le nécessitera. Cela permet d’optimiser le temps de chargement des images ainsi que de minimiser les données transférées entre un serveur web hébergeant les images et le navigateur web d’un utilisateur.
Tuilage dynamique vs tuilage statique
Cette opération peut s’effectuer selon deux modes:
- dynamique : les tuiles sont générées au moment où la requête de zoom est demandée par le navigateur. Cela évite de stocker un nombre de tuiles important sur le disque d’un serveur via un travail de prégénération de tuiles.
- statique : les tuiles sont générées en amont de l’affichage et stockées directement sur le serveur. Plusieurs formats de tuiles existent parmi lesquels : DZI (DeepZoom), Zoomify, Tiled Tiff, JPEG 2000. Les deux premiers formats (DZI et Zoomify) créent et organisent les tuiles à l’intérieur de répertoires quand les deux autres les encapsulent dans un seul fichier (JPEG 2000 et Tiled Tiff).
Pour ces deux derniers formats, l’embarquement des tuiles dans un seul fichier devrait améliorer grandement les temps d’affichage des images de grande taille, mais cela demande d’utiliser des logiciels qui soient capables de lire les tuiles à l’intérieur de ces fichiers au gré des demandes effectuées via le visualiseur IIIF (Openseadragon, Mirador, etc.). Cela ne semble pas être le cas avec le module Image Server qui, d’après les tests que nous avons effectués, génère dynamiquement les tuiles à partir de ces deux formats tuilés Tiled Tiff et JPEG 2000. Pour de grandes images et des ressources serveur limitées, le résultat est bien plus lent qu’avec des tuiles statiques en format DeepZoom.
A notre connaissance, le module Image Server génère des tuiles statiques uniquement pour les formats DeepZoom et Zoomify et uniquement pour les besoins standards de zoom sur une image. En revanche, il utilise le tuilage dynamique pour des requêtes IIIF de modifications d’images (rotation, transformation N&B, sélection de régions spécifiques) qui ne peuvent être anticipées en amont. Cela permet d’équilibrer vitesse d’affichage (avec tuiles prégénérées) et souplesse fonctionelle (génération de tuiles dynamiques uniquement quand c’est néecssaire). Comme expliqué au dessus, le module semble aussi générer dynamiquement les tuiles lors de l’utilisation de fichiers prétuilés JPEG 2000 et Tiled Tiff, même pour un zoom “normal”, ce qui peut avoir un impact significatif sur les performances.
Tests de différentes configurations du module Image Server
Première observation en effectuant les tests: avec PHP7.4, le tuilage ne s’effectuait pas sur notre serveur mais il n’y avait aucun message d’erreur relatif à la version de PHP qui permettait de le comprendre. En basculant à PHP8.1 le tuilage fonctionne.
Bonne nouvelle, même dans un cas d’usage où le tuilage ne s’effectue pas, les images peuvent tout de même s’afficher en IIIF via le module Image Server grâce à des mesures de contournement prévues par le module en cas d’absence de tuiles. On peut voir et configurer ces mesures dans les paramètres généraux d’Omeka-S rubrique Image Server:
Processeurs d’image
Les tests ont été effectués sur Ubuntu 24.04.
Le processeur d’image Vips a été installé préalablement aux tests qui suivent.
Sur un système comme Ubuntu son installation est très simple:
sudo apt install libvips
sudo apt install libvips-toolsIdem pour le processeur Image Magick :
sudo apt install imagemagickConfiguration avec un format de tuilage JPEG 2000
Le format de tuilage sélectionné, ici JPEG 2000, est utilisé quel que soit le format initial du fichier image. Dans les exemples ci-dessous les format de fichiers images associés à mon item de test dans Omeka S sont JPG, PNG, JP2. Le fait d’associer des images JPEG 2000 ou Tiled Tiff à un item Omeka S n’empêchera donc pas le module de générer ses propres fichiers de tuiles embarquées JPEG 2000 et Tiled Tiff.
Si le paramètre create tiles automatically est coché et si vous modifiez le format de tuilage dans la configuration du module, l’opération de génération du nouveau format de tuilage sera déclenchée à la prochaine modification d’un item, qu’il s’agisse de charger un nouveau média ou bien seulement de modifier une métadonnée. Cela peut donc avoir un effet non négligeable sur les ressources serveurs lors de modifications d’items en lots.
Une fois les tuiles générées, on observe bien dans le
répertoire /files/tile les fichiers JPEG 2000
générés:
Avec un format de tuilage Tiled tiff
Comme indiqué précédemment, le format configuré ayant été modifié, lors de la modification d’un item, les medias associés sont tuilés sous forme de Tiled Tiff.
La génération automatique des tuiles ne permet pas de
préciser si on souhaite effacer ou non les tuiles d’un autre
format déjà présentes. On peut donc observer un doublon dans les
fichiers de tuiles présents dans le répertoire
tile. Nous avons en effet un fichier
.jp2 et un fichier .tif pour une même
image originale. Conserver plusieurs formats prend de la place.
Il peut donc être utile de nettoyer le répertoire
/files/tile lorsque vous observez ce type de
“doublons” lorque vous passez en production.
Fonctionnalité à manier avec précautions!!
Il est possible de supprimer les tuiles déjà générées avant d’en
créer de nouvelles, via l’onglet de configuration
Bulk prepare tiles and sizes du module
Image Server. Pour ce faire, il suffit de
cocher Remove tiles and associated metadata puis de
cliquer sur Process. Si vous ne remplissez pas le
champ query toutes les tuiles associées à
l’ensemble de vos images seront supprimées. Il est possible de
réduire le scope de suppression par exemple en
sélectionnant uniquement les tuiles liées à l’item d’id 1 via la
requête id=1.
De même, les fichiers Tiled Tiff générées sont plus volumineux que les fichiers JPEG 2000. Il peut donc être intéressant de préférer ce dernier format au détriment du Tiled Tiff qui est plus lourd.
Il est important de déterminer le contexte d’implémentation afin de choisir le format de tuilage le plus judicieux pour votre usage. Par exemple, comme expliqué plus haut, les tests effectués sur notre serveur ont révélé de mauvaises performances avec les formats de tuile JPEG 2000 et Tiled Tiff pour afficher des images volumineuses (> 100Mo). Dans notre cas de test, le format le plus rapide est sans conteste DeepZoom.
Avec un format de tuilage DeepZoom
Comme indiqué plus haut, DeepZoom a montré de meilleures performances dans les conditions de ressources machines que nous avons à disposition. Nous ne testerons pas l’autre format de tuiles statiques Zoomify car il est déconseillé par le développeur du module et semble avoir été conservé pour des raisons historiques liées au développement du module.
Un format DeepZoom
est constitué de 2 parties: - Un répertoire qui accueille toutes
les tuiles liées au même média - Un fichier en .dzi
qui décrit la taille de chaque tuile et le format de fichier
image des tuiles tel que décrit par la documentation
de Deepzoom. Par exemple:
Dans le répertoire, les tuiles sont organisées par niveau de zoom (de 0 à 13 ci-dessous):
le fichier
vips-properties.xml, qui est situé dans le répertoire des tuiles, contient les métadonnées techniques de l’image originale. Il est généré automatiquement par Vips.