IIIF and museum-digital

Many have seen it and the feedback has been consistently positive thus far: For many objects, museum-digital can now offer a revamped image viewer with improved features, such as a much better zoom function. This is made possible by the image viewer Mirador and our IIIF API.

The fact that museum-digital offers an IIIF API at all, and that a IIIF viewer ist now used at museum-digital, is noteworthy, but quick to report. Especially, since both IIIF and Mirador are very well-documented on their own websites (IIIF und Mirador).

But if one looks into it deeply, it becomes obvious, that the IIIF-based image view is not available for all objects.

Limitations of museum-digital’s implementation of IIIF

IIIF offers a standardized API format for retrieving image metadata through an appropriately formulated URL, but it also enables the retrieval of image files that are cropped or rotated accordingly on the server side. This server-side image editing is useful for making IIIF-based applications run on low-powered devices and it provides easily referencable URLs for specific sections of an image. But it also means, that all images made available through the IIIF API should be available on the server itself in a high resolution.

At museum-digital, museums can upload their images – but since some museums have their own image servers, museums can also link images from external sources. In this latter case, museum-digital only stores previews up to a width of 500 pixels. These previews are however not usable for an adequate server-side image editing as required for implementing IIIF. Thus we offer IIIF manifests only for objects that exclusively have locally stored images.

We currently also implement IIIF only in version 2.1, which does not yet support other media types such as PDFs, videos, audio files or 3D representations of objects. Hence, objects that have any linked representations of these types are also excluded from the IIIF API.

IIIF Collections

One of the nicer features of IIIF are IIIF collections, with which many objects / manifests can be grouped into a collection. For implementing the minimal requirements for an IIIF API two years ago, we had thus far already set up the relevant files for IIIF collections – but we didn’t fill them with contents.

Now, IIIF collections at museum-digital represent collections and object groups. The limitations described above persist however: IIIF collections at museum-digital only list objects with exclusively internally stored images.

IIIF collections can be accessed – as always – by their respective URL. E.g.:

https://brandenburg.museum-digital.de/apis/iiif-presentation/collection/c217

This URL represents the collections of paintings of the Stiftung Preußische Schlösser und Gärten. The noteworthy section is the last: c217. Since the IIIF collection API at museum-digital represents three different types of groupings at once – institutions, collections, and series / object groups – the first character of this URL section represents the respective type of grouping. The ID of the entry follows.

An “i” in front of the ID thus represents institutions, an “s” represents series. One example of a IIIF collection for an object group may thus be:

https://hessen.museum-digital.de/apis/iiif-presentation/collection/s20