Closed regisrob closed 4 years ago
Je suis en train de séparer le serveur d'images intégré et le serveur de manifestes. Ce sera plus simple pour prendre en compte votre besoin.
Ok, bonne nouvelle. On aurait donc deux modules distincts, pouvant fonctionner ou non de concert, selon les besoins ?
Le principe, c'est que le serveur d'images déclare ses fonctionnalités ; ensuite le serveur iiif crèe les manifestes en fonction de ces fonctionnalités (taille d'images supportées, manipulations possibles, etc.).
Ok merci, j'ai intégré le code pour les versions 2 et 3 de l'api.
En fait, il n'y a pas besoin de code pour gérer d'autres serveurs d'images, il suffit effectivement d'utiliser le media IIIF image.
Include IIIF images into the Manifests generated by IiifServer
Voici un premier jet permettant de rendre IiifServer compatible avec les types de Médias "Image IIIF"... Le cas d'usage premier est celui dans lequel une institution dispose d'un serveur d'images IIIF dédié (soit en le maintenant elle-même sur ses serveurs, soit en recourant à un service tiers), et donc pour qui seule la partie création de Manifests IIIF du présent module n'est utilisée. Les URLs info.json des lots d'images peuvent ainsi être importées dans Omeka-S (via CSVImport par ex. si cela est bien possible), et les images distantes IIIF affichées directement dans UniversalViewer ou autre visualiseur via le Manifest produit par IiifServer.
Ce scénario vous semble-t-il pertinent d'être supporté par ce module en l'état ? Ce premier essai vous paraît-il valable du point de vue du code ? (j'ai essayé de prendre en compte la plupart des cas pouvant survenir avec les différentes versions de l'API Image et des niveaux de conformité existants, sans pour autant les supporter tous de façon exhaustive, notamment pour ce qui est du level0...).
En espérant que cette solution soit acceptable et qu'elle puisse s'inscrire dans la feuille de route de développement de ce module.