Some IIIF-y Collections

If you are someone who likes to view our collections, you may have noticed what looks like a slight cosmetic change in our collections pages. Honestly, even if you use our site heavily, you may have missed it. A side-by-side would show all that really changed was a new title bar, a few new buttons on the viewer, and another new button down at the bottom right next to the permissions request button:

And really, the cool thing isn’t the viewer itself, but rather why we changed the viewer in the first place. That change came shortly after the Smithsonian adopted the International Image Interoperability Framework (IIIF) back in May 2018. The viewer switch was simply a switch to a IIIF enabled viewer.

What is IIIF? To quote IIIF, it is a “set of shared application programming interface (API) specifications for interoperable functionality in digital image repositories.” What that really means is it’s a way for cultural heritage institutions to make their collections accessible and shareable via a common protocol. In short, it allows people to pull images from different institutions and view them side by side in the same player. For example, this version I pulled from collections.si.edu, one image from the National Museum of American Art, the other from our collection:

The way you can go about doing something like the example above is by using the manifest files. In order to get ours, it’s as simple as clicking on that new, yellow IIIF button next to the reference request. The site will open a page that has a bunch of code. You don’t need to do much other than drag the URL into any IIIF enabled player. In this example, Mirador.

But wait, there is more!

As you may have noticed with our collections, there’s this ability to zoom in and out quickly. What actually happens is when the page loads, a smaller images is loaded to the viewer, and when you zoom into a region, an image server slices up the region your viewing and loads that. So you are never loading more than you need. This cuts down on load times, server bandwidth used, etc.

Remember I mentioned before that IIIF uses standardized API to function, one of which is the image API that powers the tiling functionality. So, let’s take, for example, a series of cyanotypes from the National Museum of American History of a mule, named Denver, on a swing:

It’s still the same image source, the server is just returning a different section of it. One that’s a bit more useful. In fact, we can have a bit of fun with it, by using community contributed code (in this case, Compariscope) to cycle through the different cyanotype slides. This puts these motion study images into motion, and what we are left with is a clip of a mule, on a swing: