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
17 stars 11 forks source link

Accessing big images through IIIF manifests is extremely slow #42

Closed Falteri closed 8 months ago

Falteri commented 1 year ago

With IIIF Server and Image Server (Omeka S 4.0.1, iiif server 3.6.12 and image server 3.6.13), opening images through manifests in an external Mirador Viewer page is extremely slow, especially with bigger images. Same images opened in the Opeaseadragon default viewer opens very quickly and the zoom is extremely fluid. I tried to investigate more and it looks to me the responsible for the slowdown is the IIIF Server, even I cannot be sure as I’m not completely aware of how IIIF Server and Image Server work together. I try to explain. I made a test accessing this item: http://corpuspitturafiorentina.bmlonline.it/s/cennino-cennini/item/331 where the image media is opened directly with Openseadragon. Then I open the same media in another browser tab, using Mirador through the button “Confronta immagini in Mirador”. With the two tab active, I opened the development tool of the browser (F12) and I made a recording of the same zoom in both the interface. What I saw then is that in Mirador the number of calls are exatly two times those in Openseadragon. In fact, while the request in Openseadragon default viewer are directly to the tiles of the image, using IIIF Manifest in Mirador request a double call for each tile, where the first is for the IIIF default.jpg resource of the specific tile, and the second is the redirect to the real image. This is an example of a tile call:

Openseadrogn (not using IIIF) 13:10:52.862 GEThttp://corpuspitturafiorentina.bmlonline.it/files/tile/gentile.adorazione/gentile.adorazione.2018.martellucci_files/12/2_8.jpg [HTTP/1.1 200 OK 102ms]

Mirador (using IIIF) 13:10:40.790 GEThttp://corpuspitturafiorentina.bmlonline.it/iiif/2/14377/4096,16384,2048,2048/256,/0/default.jpg [HTTP/1.1 302 Found 961ms]

13:10:41.743 GEThttp://corpuspitturafiorentina.bmlonline.it/files/tile/gentile.adorazione/gentile.adorazione.2018.martellucci_files/12/2_8.jpg [HTTP/1.1 200 OK 65ms]

As one can see, when IIIF Manifest is involved, the call for the default.jpg took about ten times that for the real image, and this seems to be the reason of the slowdown and timeouts I see.

Is this behavior expected? Is there any trick to make that process faster? Checking other IIIF servers, those don’t show the same behavior when calling for resources like /iiif/2/14377/4096,16384,2048,2048/256,/0/default.jpg, i.e. I don’t see the same systematic redirection I see in Omeka.

Another strange things I noticed, is that Mirador, using the IIIF Manifest provided by IIIF Server in OMEKA S, seem to load nonexistent tiles at the border of the image that are not called when same image is opened in the default Openseadragon viewer

Daniel-KM commented 8 months ago

There are many speed improvments in last versions (iiif server 3.6.19 and image server 3.6.16). The fact that openseadragon is quicker is related to the fact it uses the tiles directly, but it cannot be done via iiif standard, where the urls are normalized. For the border tile, there seems to be an issue in image server.