search

Daniel-KM / Omeka-S-module-IiifServer

IIIF Server is a module for Omeka S that adds the IIIF specifications to serve any images and medias.
Other
16 stars 11 forks source link

Problème d'affichage des images en taille réelle / problem retrieving full-size images #6

Closed jeau closed 3 years ago

jeau commented 5 years ago

Bonjour

J'ai peur de mal exprimer en anglais les difficultés que je rencontre

Si je demande une image en taille réelle en prenant default comme paramètre de qualité, /full/full/0/default.jpg je constate une redirection vers l'url de l'image originale files/original/7576501b26831957a9046ae88e165c33589f894e.jpg

ce qui n'est pas le cas avec color /full/full/0/color.jpg où l'url est conservé et le rendu correct

Ce comportement est celui constaté avec une image chargée simplement sur le serveur.

Les images que nous avons sont assez grosses, elles ont été importées sur le serveur via sideload et converties en tuiles via le script magick-slicer https://github.com/VoidVolker/MagickSlicer.

Je constate alors un autre dysfonctionnement dans le rendu des images en taille réelle. Le paramètre de région à full avec la qualité default renvoie une miniature après redirection. La redirection n'existe qu'avec la région à full.

Avec color j'ai le même problème, une vignette à la place de l'image entière, mais pas de redirection.

Par ailleurs, le rendu de ces images converties préalablement en tuiles ne semble pas fonctionner correctement, par exemple 0,0,500,500/600,230/0/default.jpg renvoie une vignette de 230px au carré après un très long temps de traitement

th

Daniel-KM commented 5 years ago

Bonjour,

Il n'y a nulle obligation nulle part d'écrire en anglais, c'est un effet de mode et probablement son apogée.

Comme indiqué dans le readme, IIIF Server regroupe deux fonctionnalités : un créateur de manifestes iiif et un créateur/serveur de tuiles. Ils ont été conçus il y a assez longtemps pour Omeka Classic, à partir de code plus ancien. L'idée était d'offrir un outil simple pour afficher de grandes images en respectant les standards. En pratique, les principales fonctionnalités du standard iiif sont implémentées, mais elles ne le sont pas toutes de manière efficace.

Sur le premier point, l'idée était d'économiser du temps de traitement en renvoyant les fichiers originaux lorsque c'était possible. C'est un point assez facile à corriger. Le troisième point ressemble à un bug, également simple à corriger.

Sur le second point, je viens d'ajouter un job pour créer les tuiles en lot directement depuis l'interface (config), et pas seulement lors de l'import manuel (en dzi ou zoomify).

Le dernier point est le plus complexe à traiter. Lorsque les tuiles sont récupérées manuellement avec des taillles aléatoires, le module ne trouve pas de tuile existante, et il en recrée une à partir de l'image originale. Il pourrait en recréer une en assemblant des tuiles existantes, ce qui serait plus rapide, mais il faudrait un algorithme pour identifier les bonnes tuiles. C'est une solution à implémenter. En pratique, cela ne pose pas de problème pour les visionneuses, qui ne sont pas bête et qui utilisent toujours les numéro et taille des tuiles indiqués dans le fichier dzi ou équivalent (256 px). C'est donc un problème réel, mais secondaire pour la plupart des sites qui utilise ce module et les modules associés (UniversalViewer, Mirador, DIva).

Quoi qu'il en soit, j'envisage toujours de diviser le module en deux. J'ai déjà reperé qu'il existe désormais des serveurs d'image en php plus spécialisés et donc plus performants, notamment https://github.com/klokantech/tileserver-php ou https://github.com/conlect/image-iiif. L'idée serait donc de créer un module en intégrant une bibliothèque plutôt que de maintenir mon code. Il en est de même pour la partie iiif, il existe désormais de nombreuses bibliothèques spécialisées qui pourraient être utilisées.

Cependant, je n'ai pas encore de budget pour cela et ce n'est pas donc une priorité dans l'immédiat.

jeau commented 5 years ago

Bonsoir

Je n'ai pas de complexe par rapport à l'anglais, cependant au vu travail considérable que tu effectues pour la communauté Omeka, je trouve préférable d'être compris par le plus grand nombre possible d'usagers et de contributeurs.

je te remercie pour ces explications.

Je vais voir si nous avons réellement besoin de récupérer des zones particulières où si il s’agissait seulement de tests.

th

jeau commented 5 years ago

en investiguant un peu plus avant, je constate qu'il y a un seuil à 800 pour les médias convertis en tuiles

/full/800,/0/default.jpg rend correctement l'image entière dans un format homothétique de 800 pixels de largeur

alors que /full/801,/0/default.jpg renvoie après redirection une vignette

regisrob commented 5 years ago

Un ticket Github n'est pas vraiment l'endroit approprié pour un échange de ce type... je me permets quand même quelques remarques suite à cet échange.

En faisant quelques tests de ce module, j'ai rencontré les mêmes problèmes que Thierry.

L'idée était d'offrir un outil simple pour afficher de grandes images en respectant les standards.

L'idée de pré-générer des tuiles d'images statiques a certes l'avantage d'assurer un niveau de performance intéressant pour la consultation, quelle que soit la taille de l'image d'origine. Il y a probablement quelque chose qui m'échappe dans le fonctionnement du module, mais de ce que j'en ai compris en regardant un peu plus en détail son fonctionnement, l'implémentation du protocole IIIF (API Image) semble en réalité dépendante du protocole DeepZoom. Par exemple si le Tiler échoue dans la création des tuiles (ce qui m'est arrivé en testant avec des images JPEG2000 fournies par un prestataire de numérisation) et qu'il ne produit ni de fichier DZI ni tous les dérivés d'images qu'il faut dans files/tile/, alors le protocole IIIF est inopérant.

Au passage, je pense que le support de JPEG2000 mériterait d'être mieux documenté (sachant que ce format risque d'être de plus en plus usité par les bibliothèques à l'avenir) :

Par ailleurs, pour une raison inconnue, le processus de tuilage de certaines images JP2 provoque un emballement de la consommation CPU et RAM et semble tourner indéfiniment (plusieurs heures pour une image pas si grande que ça : 6622 × 9062 par ex., 18 Mo). J'ai carrément été obligé de rebooter pour arrêter le processus...

En pratique, les principales fonctionnalités du standard iiif sont implémentées, mais elles ne le sont pas toutes de manière efficace.

C'est un autre point problématique, notamment vis-à-vis de l'implémentation de l'API Image, qui ne passe pas les tests de validation (pourtant le README dit "The full specifications of the International Image Interoperability Framework standard are supported (level 2)").

Avec le level 2, le serveur est censé supporter des requêtes sur des zones d'images de manière arbitraire, avec n'importe quelle combinaison de paramètres, ce qui rejoint la discussion sur le 3e point soulevé par Thierry. Or IiifServer échoue sur les 6 tests suivants pour le level 2 de l'API Image (à moins que ça corresponde à des bugs du validateur...) :

Sur le level 1, il échoue sur au moins 2 tests :

Donc du point de vue d'un client IIIF le niveau de conformité indiqué dans le profile du info.json n'est pas une donnée fiable, ce qui peut poser problème dès lors que l'interopérabilité devient un aspect essentiel d'une bibliothèque numérique (même si de fait ça marchera toujours bien dans UV installé sur ma bibliothèque numérique).

Sur le premier point, l'idée était d'économiser du temps de traitement en renvoyant les fichiers originaux lorsque c'était possible. C'est un point assez facile à corriger. Le troisième point ressemble à un bug, également simple à corriger.

Oui c'est clairement une bonne pratique de renvoyer certaines tailles d'images vers des fichiers statiques. Par exemple dans l'API Image il est recommandé d'indiquer dans sizes des tailles d'images optimisées (pour lesquelles le serveur est censé répondre rapidement, parce qu'il les a à portée de main sur le disque, ou dans un cache pré-calculé...).

Je ne sais pas si le fait de rediriger les URL vers les URL Omeka posent réellement problème, même si l'idéal serait peut-être de conserver la syntaxe IIIF de ces URL, sans redirection.

Le dernier point est le plus complexe à traiter. Lorsque les tuiles sont récupérées manuellement avec des taillles aléatoires, le module ne trouve pas de tuile existante, et il en recrée une à partir de l'image originale. Il pourrait en recréer une en assemblant des tuiles existantes, ce qui serait plus rapide, mais il faudrait un algorithme pour identifier les bonnes tuiles. C'est une solution à implémenter.

Sur les tuiles aléatoires, voir le point précédent par rapport au support du level 2 de l'API Image. Cela dit, si le serveur est capable de récréer une tuile de manière dynamique quand il ne trouve pas de tuile existante correspondant à la requête, alors je ne comprends pas pourquoi il ne semble pas pouvoir répondre à des requêtes arbitraires (ce que semble rapporter les tests de validation IIIF plus haut). En principe ces deux URL devraient renvoyer exactement la même région d'image :

Sauf que... à l'inverse IiifServer se débrouille très bien si on lui donne des coordonnées en pourcentage :

Il y a donc un dysfonctionnement quelque part, ou quelque chose qui m'échappe très certainement...

Remarque à ce sujet : Pour recréer dynamiquement cette tuile "aléatoire", je suppose que l'image originale toute entière doit être mise en mémoire côté serveur. Je crois comprendre d'après d'autres sources qu'ImageMagick atteint ici ses limites dans la mesure où il ne supporte pas des fonctionnalités avancées de lecture de l'image permises par des librairies spécialisées d'encodage/décodage de formats d'images tuilés (par ex. Kakadu et OpenJpeg pour le JPEG2000). Je me demande s'il ne serait pas souhaitable de déléguer complètement cette partie de traitement dynamique de l'image, et donc aussi le support de l'API Image de IIIF, à des logiciels dont c'est le boulot, à savoir les serveurs d'images IIIF (https://github.com/IIIF/awesome-iiif/#image-servers).

En pratique, cela ne pose pas de problème pour les visionneuses, qui ne sont pas bête et qui utilisent toujours les numéro et taille des tuiles indiqués dans le fichier dzi ou équivalent (256 px). C'est donc un problème réel, mais secondaire pour la plupart des sites qui utilise ce module et les modules associés (UniversalViewer, Mirador, DIva).

En effet, les visualiseurs vont bien se débrouiller avec ça et se baser sur ce qu'ils trouveront dans le fichier info.json. En revanche, je pense que le problème va devenir de moins en moins secondaire pour les bibliothèques numériques à l'avenir. La possibilité de rendre citable des régions d'intérêt au sein de l'image est une fonctionnalité qui risque d'être de plus en plus couramment demandée. C'est d'ailleurs en lien avec les fonctionnalités d'annotations qui vont probablement se développer elles-aussi (ce qui induit dans une certaine mesure la capacité d'afficher correctement n'importe quelle zone d'image correspondant à la zone annotée, voir par ex. https://stanford.edu/group/texttechnologies/cgi-bin/globalcurrents/galleries/ln.html ou https://demos.biblissima.fr/ovide-moralise/)

Quoi qu'il en soit, j'envisage toujours de diviser le module en deux. J'ai déjà repéré qu'il existe désormais des serveurs d'image en php plus spécialisés et donc plus performants, notamment https://github.com/klokantech/tileserver-php ou https://github.com/conlect/image-iiif. L'idée serait donc de créer un module en intégrant une bibliothèque plutôt que de maintenir mon code. Il en est de même pour la partie iiif, il existe désormais de nombreuses bibliothèques spécialisées qui pourraient être utilisées.

Ca me paraît être une bonne piste. Apparemment Intervention ne supporte pas le JPEG2000 donc à priori ça ne résoudrait pas le problème avec ce format par rapport au module actuel.

Cependant, je n'ai pas encore de budget pour cela et ce n'est pas donc une priorité dans l'immédiat.

C'est tout à fait compréhensible. Et j'espère que ces évolutions pourront être financées à un moment donné...

jeau commented 5 years ago

Je ne comprend plus, je n'ai pas les mêmes problèmes sur mon serveur de dev...

il faut que je compare les librairies et les versions installées (j'ai bien imagemagick-7 avec la prise en charge de JPEG2000)

th

jeau commented 5 years ago

En fait non, désolé, c'est simplement que ces images n'avaient pas été transformées en tuiles.
J'ai oublié de préciser que les originaux sont en jp2 et les tuiles en jpg

jeau commented 5 years ago

on peut récupérer une image entière en précisant la taille en pourcentage : /full/pct:60/0/default.jpg

il me semble que la limite à 800 en paramètre de taille pour récupérer les images dans une dimension aléatoire est celle par défaut de l'image dérivée large.

Daniel-KM commented 4 years ago

Bonjour,

J'ai divisé le module en deux et on peut donc désormais utiliser iiif server avec un autre serveur d'images (version 3.6.0-beta). Pour utiliser les images d'un autre serveur, il suffit de créer les items avec des medias de type "IIIF image" (type standard d'Omeka) et de donner l'adresse du fichier info.json. Il y a eu aussi beaucoup d'autres améliorations (iiif api v3).

Néanmoins, je vais continuer d'améliorer les performances du serveur d'images (module Image Server) pour éviter d'avoir à installer un serveur spécifique. La piste principale actuellement est de convertir les images originales en jpeg 2000 plutôt qu'en tuiles, puisque jpeg2000 a été conçu pour faciliter ces extractions de zones et qu'il n'y a plus de brevets depuis le début de l'année. Sinon, il faut que j'améliore l'algorithme d'extraction via l'assemblage des tuiles.

jeau commented 4 years ago

Bonjour

Merci pour ce travail de corrections de bugs et d'améliorations. Il ouvre de nombreuses perspectives.

j"ai testé les deux installations sur un même serveur et avec les mêmes documents et images (originaux en jp2, tuiles pré-générées au format Deep Zoom et utilisation de l'extension PHP Imagick). Avec les dernières versions IIIF Server version 3.6.0-beta.6et Image Server version 3.6.0-beta.5j’obtiens de bien meilleures performances qu'avec les précédentes versions (cf https://github.com/Daniel-KM/Omeka-S-module-ImageServer/issues/2). Elles dépassent même largement celle de l'installation initiale avec le module unique IIIF Server version 3.5.16.

Daniel-KM commented 3 years ago

Ce bug a été corrigé dans la dernière version d'IIIF Server et d'Image Server.

Il y a aussi une nouvelle fonctionnalité : les tuiles sont désormais créées pour toutes les images par défaut et sont gérées comme les autres formats (large, medium). Il y aura quelques nouvelles améliorations prochainement.

jeau commented 3 years ago

merci Daniel Th

Le mar. 24 nov. 2020 à 18:40, Daniel-KM notifications@github.com a écrit :

Ce bug a été corrigé dans la dernière version d'IIIF Server et d'Image Server.

Il y a aussi une nouvelle fonctionnalité : les tuiles sont désormais créées pour toutes les images par défaut et sont gérées comme les autres formats (large, medium). Il y aura quelques nouvelles améliorations prochainement.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Daniel-KM/Omeka-S-module-IiifServer/issues/6#issuecomment-733132635, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAX37U3XF6U32EPSVYT35QDSRPV2PANCNFSM4GYMO6VA .

-- Thierry Pasquier Responsable de l'édition et de la communication Portable : 06 01 27 54 14

Espace Mendès France — Poitiers Centre de culture scientifique, technique et industrielle en Nouvelle-Aquitaine Tel 05 49 50 33 00 — emf.fr https://emf.fr 1 place de la Cathédrale CS80964, 86038 Poitiers cedex, France

Revue L'Actualité Nouvelle-Aquitaine https://actualite.nouvelle-aquitaine.science/