Thumbnail creation with IIIF Image media

Omeka S Development
1

I have an Omeka v4 installation where I am experimenting with different ways to approach media. We likely have the requirement to use an external image server (instead of Daniel-K Image Server) and so I have installed Cantaloupe, created some tiled pyramidal tiffs and have attached them to an item using IIIF Image. The images are attached fine and behave as expected in the browser, but no thumbnail is created. Cantaloupe literature says it creates runtime thumbnails but I see no configuration switch to enable or disable. I do not see some specific form of URL for the IIIF Image attachment that might include a thumbnail that is embedded in the TIF.

Anyone know how to solve for this?

2

The “IIIF Image” media type should create a locally stored thumbnail.

Do thumbnails get created if you directly upload an image? You could just have a problem with thumbnail creation on your server.

3

Hello - I did some experimenting with this the other day as I wanted to better understand how Omeka-S manages images (versus with an image server of some type). Here are my observations thus far (in all cases the image is a plain vanilla tiff (no tiles nor pyramid) in the same directory: /var/www/[website]/files/Images/ )

  • Uploading an image via https URL on a plain vanilla v4 Omeka-S with Apache2 as web server gives a thumbnail.

  • Uploading the same image via https URL with module IIIF Server installed also gives a thumbnail (as well as the tiled image)

  • Uploading the same image via IIIF Image http URL on port 8182 with Cantaloupe’s default web server does not give a thumbnail but does link the media to the Cantaloupe served tiff.

  • I have not tested Cantaloupe behind Apache2

From your response I am guessing somehow the thumbnail app is not visible when I use IIIF Image this way?

4

What IIIF Image does for thumbnails is: it requests the “full” image from the IIIF image server and makes our thumbnails of it locally.

If your image server is rejecting that request, that could result in what you’re seeing.

5

Okay, thank you. I will investigate that. Just so I am clear, there are separate requests for displaying the image versus thumbnail creation? I ask as the image displays fine (including the zoom-pan).

6

For actual display, the IIIF Image media type just uses the remote image server.

The initial one-time request for the max-dimensions image is just used to create a thumbnail we can use in places like browse pages.

7

See pull request Moved creation of thumbnail urls from MediaRepresentation to ThumbnailManager. by Daniel-KM · Pull Request #2140 · omeka/omeka-s · GitHub for a first step (required in core) to fix this point and to be able to create thumbnail dynamically via the external image server.

1 Like
8

As it is getting closer to our implementation dates, I wanted to check back on this. I see the discussion on github. I have not tested this further to see if perhaps my prototype configuration was wrong or why else the thumbnail step did not work with the Cantaloupe server but did work with DK’s IIIF Server Module. Any updates or further thoughts on this?

9

So my guess still stands, it’s probably an issue with the request that’s getting made for the image we’re going to make a thumbnail of.

For IIIF Image API version 2, we’ll request “/full/full/0/default.jpg” from your image base URL.

For version 3, it’s “/full/max/0/default.jpg” .

You could put together one of those requests yourself, whichever is appropriate for the IIIF API version your image server is using, and see what’s happening, if there’s a timeout, if the server is rejecting the request, etc.