How to simply set up IIIF images for your small archive

For the last few years, I have been in search of a way to host images, text and other types of content on the internet in a no-code or low-code but organized and categorized setup. This has led me to many interesting places and ways of doing this. In this article, I want to talk about hosting images using self-hostable tools.

To briefly talk about why I set about looking for such solutions - I am part of few collectives that work with cultural and creative practice-based research in Karnataka, India. As is, in the course of our work, we come across some interesting collections and collectors of images for different purposes.

A few examples include a researcher studying Memes and Dissent in India looking to have large hoards of images annotated as a community, a 70-year old collector with pictures of a place from a time when very very few pictures exist and a group of dargahs with objects of centuries-old storied traditions. A group of community health workers collecting images and stories of locally available foods, diets and mythologies, multimedia annotations created by performance artists for other artists from a different tradition/discipline. Each of these examples, require a hosting and publishing solution customizable and annotable metadata and a relatively simple user-management featureset. This need for annotable archives resonated with work I had done on Milli- which I also presented at International Archives Week- for textual metadata and Papad for oral and audio archives. Back in 2021, I experienced how arbitrary and niche the process of creating a panable, zoomable and annotable image was.

At that time, I was using OpenSeadragon+Annotorious as a way to create the map in this Compost.mag piece It felt like magic to be able to path that together with whatever little code I knew, like I had cracked it.

"This could be used EVERYWHERE!"

But I found out soon enough - not really!

It felt like every new image I wanted to use this in way would need its own unique pipeline and dedicated resources.

This felt wrong, that something like this wasn't a native web standard like html. If we are able to annotate text this easily why are images so much harder.

It seemed to be something that could only easily be made in walled-garden platforms.

While working through this problem in 2020, something standing out as having potential was this framework called IIIF (triple-eye-eff) - International Image Interoperability Framework. It was describing a solution that felt a little good to be true.

Yet I saw Archive after Archive listed as examples. I couldn't believe that these viewing experiences weren't custom-built monoliths and were based on a standard implementation that I could use if I tried.

I started reading up about it and coming back to it every two months. For a non-technical person like me, it was quite a dense topic to understand. So I tried to learn it by saturation and osmosis.

It was during that time that I started experimenting with Cantaloupe, a IIIF image server. We self-hosted it on a server that our collective owned. After getting to the point of being able to serve singular images, I came across the biggest issue. How do I actually organize, metadatize, annotate and then serve these images? Grappling with the complexity of IIIF

{{< figure src="IIIF system.png" alt="A limited explanation of IIIF" caption="Schematic of how images are requested for and served" >}}

• This image is a diagram illustrating how the IIIF (International Image Interoperability Framework) works to manage, display, and secure digital images in an online setting.
• The process begins with the IIIF Image Server, where image files and accompanying metadata files (info.json) are stored.
• This server has the capability to transform images (e.g., resizing, rotating, format conversion) based on user needs and is typically accessible over a network.
• The images are then made available through an Image API that enables users to retrieve images in different sizes and formats without needing separate versions of each file.
• This capability allows users to zoom into detailed sections of images, which is especially useful for high-resolution images of artwork or historical documents.
• In another location on the internet, the users create Manifest.json files and stored as bundles that collect images, metadata (e.g., title, description), and structural information (e.g., page order) to organize images or collections for online display.
• These manifest files are passed to a IIIF viewer in a web browser or application, allowing users to view images with embedded metadata.
• The IIIF viewer can utilise additional APIs, such as the Authentication API for access control to restrict certain content and the Search API to enable text searching within images (e.g., searching for keywords in handwritten documents).
• The manifest.json made according to the Presentation API provides display instructions to the viewer to ensure the images and metadata are presented cohesively. This API supports annotations and custom display settings.

As far as my usecases went, this was overkill and far too complicated of a individual or a small archive. So I was looking for opportunities to simplify the stack of things that had to be put together.

As I saw it there 3 main areas where the complexity was really high

The Image Server -

The traditional IIIF image server is a dynamically serving images, cut up into tiles (like maps) - so that they can be viewed at a high resolution. It stores the image, and an accomanying info.json that has instructions about the nature of the image (size, resolution etc.) This has been defined in the Image API.

{{< figure src="IIIF URL processing.png" alt="Dynamic images and how URLs like these fetch them" caption="Dynamic images and how URLs like these fetch them" >}}

A simplification that was offered online was to serve static tiles of that don't do any transformations.

{{< card type="note" title="Example" >}} If you think of using Google Maps with a slow network, the squares often take time to load when zooming in or out of the map. Google maps to some extent is dynamically creating these square tiles with upto 22 levels of zoom. {{< /card >}}

{{< figure src="Zoom_Levels_Tiling.png" alt="At each Zoom Level, the image is cut up into smaller and smaller tiles - Deep Zoom" caption="At each Zoom Level, the image is cut up into smaller and smaller tiles - Deep Zoom" >}}

However, if you were able to limit the viewing to 1 or 2 zoom levels, the tiles can be created once and reused again and again. This is hitting the tradeoff between performance and memory usage.

A github repo with the images pre-cut into tiles at different zoom levels and corresponding tiles and info.jsons could behave like an IIIF image server.

{{< card type="note" title="Example" >}} You can see an example of static tiles in this repository of cat pics {{< /card >}} This also removes the need for the image URL to be complicated and can be generated according to a formula around the filename.

Manifest Creation:

Manifest/manifests a JSON file which bundles up all the different elements of an IIIF object (such as a single image, or a series of images) with basic metadata (like title, description, and rights information) and structural information (such as page order). According to the Presentation API, here are a few types of properties that a manifest can hold

• Descriptive and Rights Properties: Include required properties (like label and metadata), with some optional and recommended properties (e.g., rights, language, and navDate).
• Technical Properties: Most properties are required for fundamental elements (like id, type), with other property attributes (e.g., height and width).
• Linking Properties: External and internal links - external include logo, see more info, images part of a range etc.
• Structural Properties: items, structures, annotations
• Behavior Values: Asks to define motivation or purpose

As you can see, putting together these things for every image in every collection without the help of a GUI felt very hard, especially because we also wanted the archivists themselves to be able to manage their archives to a large extent.

{{< card type="note" title="Example" >}} Here's an example manifest.json for a small collection {{< /card >}} There's the saying that goes, "There's understanding and then there's understanding to teach" - similarly, there's "building something to use vs building something so that others can build more easily"

The process of putting together Manifests for large quantities of images, is still quite a hard problem. To make matters even more complicated - Manifests are only part of the picture in terms of the structuring required.

Resource Types - Structuring the objects from the image server: The manifest.json is the part of the object that allows the image to work in a viewer but it is by no means alone. The IIIF Presentation API defines several resource types to structure and present complex multimedia objects. This however means, that it adds to the complexity of the Manifest Creation process.

• At the top level is the Collection, which groups multiple Manifests (representing individual compound objects like books or albums) and/or other Collections in a hierarchical way for navigation or organization.
• Each Manifest describes a single compound object, including its metadata and layout instructions for displaying the content.
• Within a Manifest, Canvases represent individual views or "pages" of the object, providing a space for arranging content resources (e.g., images, audio, or video) through Annotations. Ranges allow Canvases or sections of them to be grouped into logical sections, like chapters or scenes.
• Annotations link content resources to Canvases, creating a flexible and distributed system for adding layers of information such as translations or commentary.
• An Annotation Pag