Accessing big images through IIIF manifests is extremely slow

With IIIF Server and Image Server, 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.
These images are already tiled, but it seems that every time I access through IIIF manifest, images slices are dynamically created via vips converter.
I’m wondering if I made a wrong configuration of the Image Server module and if it’s true that I should be able to use image tiles already there, instead of dynamically create image slices for every request.
Please see this item as an example:
and click on the button “ Confronta immagini in Mirador” to open the image in Mirador. You should see the extreme difference in accessing the tile image.
Hope someone can give me an help or suggest how to config or what to check.

There is an important update of the two modules (iiif server 3.6.12 and image server 3.6.13). Check that autotiling is set and tiles all missing media via the bulk job in image server config. Try to choose “deepzoom” mode (the default one).

Thanks @Daniel_KM, I did that but the loading via IIIF still seems to be slow, even if better than before. I have a question about the autotiling option: to activate that option, as you suggest, do I have to check that option or uncheck it? The description in the Image Server config form it’s not so clear to me:

Tiling service
Tile images manually and not automatically on save
If unset, to run the task below will be required to create tiles. It is recommended to set automatic tiling once all existing items are tiled to avoid to overload the server. So bulk tile all items first below.


I can confirm that, after a massive tiling of images, there is no on the flight conversion anymore, but the access through IIIF manifest to images is still very slow and in case of big images, external Mirador Viewer goes often in timeout for a bunch of tiles.
Looking at the browser console, I can see very long time to get image tiles and many timeouts.
Any experience with such a problem? Any suggestion? Maybe Image Server + IIIF Server are not able to handle very high resolution images?

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: 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 GET
[HTTP/1.1 200 OK 102ms]

Mirador (using IIIF)
[HTTP/1.1 302 Found 961ms]

[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?

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.

Hope someone can take a look at this as this behavior seems to limit the real usage of Omeka S with IIIF, at least in my case.

I’ve just checked other IIIF servers and I don’t see 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.

Is there anyone can help me understand if this is the expected behavior of IIIF Server / Image Server when providing IIIF Manifest and images tiles?

Is there anyone can confirm this is the expected or non expected behavior? Help would be much appreciated, thanks!!