Revision as of 14:32, 30 September 2022

Part of IIIF Pages

Herbarium

The RBGE Herbarium contains approximately three million specimens. An online herbarium catalogue presents metadata on around one million of these and zoomable, high resolution images of about half of those. The specimen images are the result of a complex internal process that has developed over the last decade. The final stage of the process is to build an image tile pyramid of the specimen and store it in a ZIP file. A bespoke web service then exposes this data as Zoomify end point.

Digitisation workflow at RBGE

The system works well and the online catalogue is used both within the organisation and by researchers from around the world. There was no need to make changes to the overall process however there were two areas that made adoption of IIIF desirable. Firstly the Zoomify endpoint restricts the choice of viewers in the catalogue. Secondly, because other herbaria do not use Zoomify in the same way, opportunities for interoperability were restricted.

Implementation

We therefore built our IIIF implementation as a wrapper around our existing infrastructure (Figure 11). A relatively simple set of bespoke PHP scripts (available in GitHub) implement the Image and Presentation APIs by calling the collections metadata in an Apache Solr index (the same one that feeds the catalogue) and the existing Zoomify API for images.

Data flow through PHP wrapper to serve IIIF at RBGE

Once the IIIF service was in place and proved to be stable the existing Zoomify viewer in the catalogue was swapped out for an OpenSeadragon viewer that calls the IIIF Image API. This means the catalogue and backend are further decoupled and we could switch either out in the future if that became desirable.

Having implemented the IIIF service we were able to add the manifest URIs to our Darwin Core Archive feed to GBIF using the mechanism described in the section above. This means our specimens are displayed in the GBIF data portal with draggable IIIF icons along with those from other collections. The manifests are also available through the GBIF API for incorporation into other applications.

Future development

Looking to the future we may be able to include OCR and Citizen Science data gathered about specimens as IIIF annotations. We also hope our specimens will be exploited in IIIF based taxonomic work benches.

Padme

The RBGE herbarium catalogue is strictly limited to storing data relating to specimens stored in Edinburgh, as such it has a significantly more limited scope than Padme. Nevertheless, specimens collected by Edinburgh researchers will be stored in the RBGE herbarium, digitally imaged to a very high resolution, and recorded in the catalogue. It is therefore of significant advantage for researchers within Padme to be able to view the high-resolution specimen images alongside any images relating to that specimen stored in Padme. For example, it is common for RBGE staff to construct a montage of images documenting the specimen as it was found in the field and store them in Padme as well as the image of the dried voucher specimen taken by the herbarium.

Motivation for the Padme IIIF Image API implementation

Both the herbarium images and the images stored in Padme are available as Zoomify stacks. However, the APIs used to access those stacks were independently developed and somewhat different in character. IIIF offered a way to unify the APIs used to access images stored directly in Padme and those available via the Herbarium catalogue thus significantly simplifying the coding required to support viewing of the images.

Padme uses the OpenSeadragon viewer to display the zoomable images of objects stored in its datasets. Initially the OpenSeadragon configuration in Padme utilised the IIIF API for displaying the Herbarium images and the native zoomify tile stack viewing ability of the viewer to display the images stored directly in Padme. By implementing an IIIF image API endpoint as a wrapper around the existing Padme Zoomfiy stacks, images from both sources can be viewed simply by supplying a correctly formed URI to the viewer so that it can obtain the necessary info.json file.

Although it would only have been necessary to implement the IIIF Image API to achieve this goal, the concomitant advantages in terms of unified image sharing also made it worthwhile implementing a Padme specific IIIF Presentation API endpoint.

Padme IIIF Image API implementation

The implementation of the wrapper around the zoomify stacks was realised as a single PHP script and relatively straightforward to implement. Implementing the endpoint as a wrapper meant that all the existing code written to manage and build the stacks could be left unchanged. The only tricky part being the implementation of the logic required to recognise when a tile was being requested rather than an arbitrary region of the image. There is no mechanism in the IIIF URI scheme for explicitly requesting a tile. The current Padme IIIF Image API implementation is complete except that upscaling of image regions is not supported. Including implementation and testing, two working days were required to complete the work.

Padme IIIF Presentation API

Padme exposes three IIIF Presentation API endpoints to satisfy the three use cases for image access so far identified. These are implemented as three layers each with a standard form of URI and representing increasing levels of abstraction . As with the image API, the endpoint was implemented as a set of PHP scripts. The hardest part of this section of the implementation was recreating the nested objects required to populate a manifest. Although not technically difficult to achieve, ensuring that the correct structure had in fact been created was not so trivial. In hindsight use of a third-party library in this respect may well have saved considerable time.

Layer 1: Access to a single image.

https://padme.rbge.org.uk/padmeweb/iiif/{imageid} – redirects to the manifest https://padme.rbge.org.uk/padmeweb/{imageid} /manifest – returns the presentation API manifest for the image containing a single canvas for the image. https://padme.rbge.org.uk/padmeweb/iiif/{imageid}/info.json - returns the Image API json file https://padme.rbge.org.uk/padmeweb/{imageid}/{image/tileparams} – returns the pixel data from the specified region of the image as per the Image API specification.

Layer 2: Access to a set of images associated with an observation

http://padme.rbge.org.uk/padmeweb/iiif/{datasetid}/observation/{observationid} – redirects to the manifest http://padme.rbge.org.uk/padmeweb/iiif/{datasetid}/observation/{observationid}/manifest – returns a Presentation API manifest with a canvas item for each image associated with an observation. Each canvas item will contain a URI of the form https://padme.rbge.org.uk/padmeweb/iiif/{imageid}/info.json i.e. a reference back to layer 1.

Layer 3: Access to a set of manifests associated with a species name

http://padme.rbge.org.uk/padmeweb/iiif/{datasetid}/species/{species_name} – redirects to the manifest http://padme.rbge.org.uk/padmeweb/iiif/{datasetid}/species/{species_name}/manifest – returns a presentation API collection with an item for each observation associated with the requested species name. Each item in the collection contains a URI in the form http://padme.rbge.org.uk/padmeweb/iiif/{datasetid}/observation/{observationid}/manifest, i.e. a reference back to layer 2.

Note: Padme stores images from all datasets in a single image store. However, specimen, field note, and species records are stored within separate data sets corresponding to different projects within the Padme system. Therefore, only layer one URIs can be dataset agnostic.

Back to IIIF Home