IIIF Meise Example

From CETAF Identifiers Wiki
Jump to: navigation, search

Part of IIIF Pages

Screenshot of the data portal BotanicalCollections.be showing one of the digitized specimens.

Meise Botanic Garden holds a herbarium with about 4 million specimens. During a first mass digitization program (DOE!) an initial set of 1.2 million specimens was imaged. Currently, a second program is expected to be finished by fall 2021 bringing the total number of specimen images to more than 2.4 million. Digital data (including the images) are provided through the data portal botanicalcollections.be

As a result of the digitization workflow, the specimen images are available in three different formats: high quality TIFFs, JPEG2000 and lower resolution JPG. The main purpose of the high quality TIFFs is long term storage at MeeMoo. The herbarium portal is serving the JPEG2000 format.

Currently the lower resolution JPEG images are stored on a different server and are used to serve the Meise Botanic Garden herbarium dataset on GBIF. When developing the IIIF service, the least invasive option was to build a IIIF pilot based on the JPEG images.

Implementation of the IIIF service

Schematic overview of the current implementation of the IIIF service
Screenshot the Mirador instance at Meise Botanic Garden. A IIIF image of a Meise specimen (left) is displayed next to a RBGE specimen (right).

At Meise Botanic Garden, version 2.1 of the IIIF image and presentation APIs is currently implemented. The pilot is based on an existing server which contains the (lower resolution) JPEG images. This has implications on the choice of the image server, since most servers don’t support the use of JPEGs as an input format. In order to overcome this limitation, the choice was made to use the Loris image server. This is a python-based implementation that performs the tiling of the images on the fly. This made it easier to build upon existing infrastructure. However, there is a potential downside, since it might require much more computational power from the server side, especially when a large amount of requests are made to the server. An example of an image can be found here:

http://iiif-image.oxalis.br.fgov.be/V/BR0/000/025/668/070/BR0000025668070V.jpg/full/full/0/default.jpg

In order to generate the manifests, a python implementation is used as well (Code available on GitHub). Currently, the design is relatively straightforward and based on the unique barcode of each specimen. The barcode can be parsed and used to retrieve the URL to the image. The metadata that is transferred to the manifest is retrieved from the data portal botanicalcollections.be. Using the CETAF stable identifier (based on the barcode), it is possible to retrieve this metadata in a machine readable RDF format. An example of a manifest can be found here:

http://iiif-manifest.oxalis.br.fgov.be/specimen/BR0000025668070V/manifest

For demonstration purposes, a Mirador instance was installed on the same server and is available here:

http://oxalis.br.fgov.be/mirador/

Future development

Since the support of the Loris image server is stopping at version 2.1 of the image API, we need to adjust the architecture of the current implementation in order to move to the latest version of the IIIF APIs and since we need to redesign our IIIF service, the plan is also to check whether we can build the IIIF service on our JPEG2000 images and serve the data portal with IIIF compliant images.

Back to IIIF Home