Bring your own viewer?

Lately I’ve been focusing on replacing/upgrading our zoomable image viewer in our digital repository.  The current version of the tool lacks a few features which folks have been asking for – one of which is rotation.  In an instance where you have a manuscript that has writing in two directions, being able to rotate the image is a highly desired feature.

An image of a manuscript showing text written in two directions

Having heard about this set of standards for image viewing, I started researching the International Image Interoperability Framework (IIIF).  I’ll share a little bit of my learning with you here.

Honestly, looking at IIIF made me start to dream.  We craft websites with our (limited) view of the world and our (limited) view of the data.  Users are subjected to the limitations of the tools we choose, for better or for worse.  And as time moves on, even the best website gets outdated and the once super cool tool is no longer as interesting, especially next to its shiny new, more feature rich, replacement(s).  Generally there’s no way of getting around that and to some degree, that’s just how it is.  But what if a user who is viewing images in your digital repository could bring their own viewer?  What if they could pull in separate image data sets from different places and compare them with a single tool of their choosing?

Granted the number of “tools of their choosing” is fairly limited at this point.  However, the more that IIIF takes off, the more options users will have.   IIIF is made up of four specifications – one specifying what an IIIF image server should do, one specifying a presentation API, one for a IIIF searching service, and one for authentication API (for those times when your data can’t be open access).

That’s a lot of specifications and for the sake of this post, I’m only going to talk about the IIIF Image API and IIIF Presentation API specs.  Simply put, the IIIF Image API defines how a IIIF server should serve images over the web – a IIIF image server handles all the image manipulations requested and is able to produced zoomed in and rotated images.   That in and of itself is not a new thing, but the fact that it follows a standard means you can replace one IIIF Image Server with another and you won’t have to change the client code.   As a developer, that’s a thing to be appreciated. 

Providing a IIIF Image server alone will allow you to plug in any image client that can interact with a IIIF Image Server.  A client like Open Sea Dragon. Chances are you’ve seen that around before and it’s a great javascript tool for working with high-resolution, zoomable images.  It happens to be able to speak IIIF. 

You can stop there with the IIIF Image server and client or you can add a tool that implements the IIIF Presentation API – the playing field really opens up then.  This API specification details how one would produce configuration documents for a digital resource.  A configuration document describes how to get the images associated with the resource, some descriptive and technical metadata about the images, and any other services (like maybe a search service) associated with the resource.  Tools that implement the IIIF Presentation API are what make it possible to grab information about data sets from different institutions and compare them with one tool.   I’ll explain by example: Mirador demo site.

Mirador is able to talk to IIIF Presentation API compliant servers and pull in configuration files for resources.  These files are known as ‘manifests’ and are formatted in JSON.  The beauty of Mirador is that you, the user, can pull in any image data set you choose, so long as the publisher of that data set has generated a manifest for it.

There are a few ways to pull in a new manifest in Mirador – one way to do it is to click on the “Change Layout” link in the upper right hand corner.  Add a few more boxes (say a 2×2 grid).  Then click on “Add Item”  – that will show you the list of manifest that the Mirador demo knows about.   If you’re learning how to develope manifests yourself, it’s very handy to pull down a few of these manifests to study them.

You’ll also see that these resources come from all different institutions.  To pull in a manifest file implies that the institution also has a publicly available IIIF image server somewhere ready to serve up images detailed in the manifest.

Within seconds a user can be comparing images from different institutions, all within one tool.

When a IIIF Image server and a IIIF Presentation server are supplied a user can then make the choice – do they use the presentation layer we provide on our website or do they want to grab a manifest and view the data in their own favorite IIIF viewer? 

In the Digital Programs group here at Amherst College, our long term goal is to provide a IIIF Image server as well as a service that implements the IIIF Presentation API.   While there are many IIIF Image servers available, it’s not clear to me (yet) how many IIIF Presentation API implementations there are and we may end up writing out own.   For now, we’ll start with a new client (Open Sea Dragon) and eventually integrate a IIIF Server and maybe someday even use Mirador.


Bethany Seeger is a software developer working in the Amherst College library, focusing mainly on the Amherst College Digital Repository.  She can be reached at bseeger@amherst.edu.