A researcher comparing photographs should be able to put them beside each other, even when different institutions hold the originals. That simple wish explains the appeal of the open-source ecosystem around IIIF, the International Image Interoperability Framework. Its standards let image servers and viewers communicate across collection websites.[1] Following a photograph from storage to screen reveals why Cantaloupe, OpenSeadragon, and Mirador have different jobs—and why installing a viewer alone cannot make a collection portable.

Ohio University Libraries supplies a particularly useful starting point. Its IIIF guide points to a roll of photographs from Lynn Johnson's 1984 assignment involving the Bahamian artist Amos Ferguson. The archive describes 34 negatives and a contact sheet, with the assignment, photographer, dates, and location recorded alongside them. A single picture belongs to a larger photographic object.[1][2]

The paint tins, the drawing on the board, and the bright doorway offer different reasons to look closer. A viewing system has to make those details reachable while keeping the frame connected to the roll it came from.

First, ask for the pixels

The IIIF Image API gives an image service a predictable address structure. After the image identifier come instructions for region, size, rotation, quality, and format. A request ending in full/1200,/0/default.jpg asks for the whole image at 1,200 pixels wide, with no rotation, using the default quality and JPEG output. The service's info.json describes dimensions and supported capabilities; clients should read that information before assuming that every possible transformation is available.[3]

This is useful well before a digital exhibition becomes elaborate. A thumbnail and a close view can come from the same source through different requests. The institution can expose a stable way to ask for images while retaining its own decisions about storage and processing. The specification deliberately leaves those implementation choices outside its scope.[3]

Cantaloupe is one open-source implementation of that service. Written in Java, it generates derivatives on demand and supports IIIF Image API versions through 3.0. Its source modules retrieve images; its processors handle image operations; its caches can retain results to reduce repeated work. For a filesystem-backed installation, FilesystemSource.BasicLookupStrategy.path_prefix identifies the directory containing the source images.[4]

That configuration key points to an essential responsibility: someone still has to maintain the files and the service that reads them. Cantaloupe can answer a request for a crop. It does not decide which photograph belongs first in Johnson's roll or supply the archival description of the assignment. Those belong elsewhere in the system.

Then, explain what the reader is looking at

The Presentation API describes an object for viewing. Its central document is a manifest: a JSON description carrying information about the object and its constituent views. A Canvas represents one view, such as a manuscript page or the front of a photograph. An annotation associates an image with that Canvas. This separates the space being described from the particular image used to show it.[5]

Johnson's roll makes the distinction concrete. Ohio's manifest begins with the contact sheet and then lists individual frames. It also supplies descriptive fields, including the photographer and the archive's preferred citation. Its image-service addresses point outward to the resources that deliver the pictures. The JSON document organizes access to the photographs; it does not contain their pixel data.[2]

There is a version wrinkle worth recognizing. That live archive example uses Presentation API 2, with sequences, canvases, and images. Version 3 expresses the structure through items and annotation pages. The underlying relationship remains recognizable, but code written for one JSON shape should not silently assume the other.[2][5]

This is also why an image URL, an info.json URL, and a manifest URL are not interchangeable. Ohio's independent library guide explicitly distinguishes the image link from the manifest link. My reading of that small teaching choice is that it captures the ecosystem's central bargain: access to a picture and access to its context need separate, usable addresses.[1]

Choose the viewing tool for the task

OpenSeadragon is a JavaScript viewer for high-resolution images. IIIF is one of several image-serving protocols it supports. Its controls, overlays, and plugin system make it a useful component when a developer wants to build an interface around zooming and panning.[6]

Mirador works at the level of a research workspace. It can display manifests, show descriptive information, and place resources from different repositories beside each other. It supports version 2 and version 3 of both the Image and Presentation APIs. Creating annotations requires a plugin.[7] A deployment that promises to retain a scholar's notes must also provide an appropriate way to save them.[8]

The roles fit together like this:

The table describes one possible open-source arrangement; it makes no claim that Ohio's archive uses Cantaloupe. A smaller option also exists: precomputed image sizes and tiles served by an ordinary web server can provide a level 0 Image API implementation, including deep zoom.[8]

The collection still has work to do

For a small archive with one part-time developer, I would begin with a single representative object: several views, useful descriptions, and one awkward image. Check whether the existing repository already exports manifests before adding another service. The implementation guide notes that assembling a manifest may require information from several institutional systems; purchasing more image-processing capacity cannot resolve disagreement about page order.[8]

A team operating a dynamic image server should give caching and source access explicit owners. Cantaloupe offers several cache backends and configurable processors, so the operational workload depends on the chosen arrangement.[4] Measure it with the actual scans and viewing behavior the collection expects. A heavily browsed contact sheet and a rarely opened photograph need not produce the same request pattern.

Then open the manifest in a viewer hosted on a different domain. This is my suggested acceptance check because it exercises the promise that motivated the work. HTTPS and cross-origin resource sharing matter here: a collection can appear healthy inside its own website while browser rules prevent another viewer from retrieving its resources.[8]

Finally, retain the distinction between displaying an object and finding it. The Presentation API explicitly excludes collection discovery and search within an object from its core scope. A readable title and an orderly set of Canvases do not, by themselves, create a searchable archive.[5]

For the reader, the reward is less architectural. A photograph can sit beside another institution's photograph, with its identity still available and its details close enough to examine. The open-source tools make that viewing room possible when the collection provides reliable addresses, useful descriptions, and images that continue to answer requests.

Sources

1. Ohio University Libraries, “Finding & using IIIF images” — independent institutional guide distinguishing image and manifest links, with the Lynn Johnson collection example.
2. Ohio University Libraries, IIIF manifest for “Amos Ferguson, Bahamian folk artist and others, 1984: Roll 113145-C, 34 negatives with contact sheet” — archival metadata, ordered frames, and image-service addresses.
3. IIIF Consortium, “Image API 3.0” — request syntax, image information, compliance, and implementation scope.
4. Cantaloupe Image Server, project documentation — dynamic derivatives, sources, processors, caches, and filesystem configuration.
5. IIIF Consortium, “Presentation API 3.0” — manifests, Canvases, annotations, version 3 structure, and limits of scope.
6. OpenSeadragon, project documentation — JavaScript image viewer, supported tile sources, controls, and plugins.
7. Project Mirador, project documentation — comparison workspaces, API support, metadata display, and annotation plugins.
8. IIIF, “Guide for IIIF implementers” — static and dynamic image services, manifest generation, viewer choices, HTTPS, and cross-origin access.