Difference between revisions of "IIIF Meise Example"
Roger Hyam (Talk | contribs) |
Roger Hyam (Talk | contribs) |
||
| Line 28: | Line 28: | ||
http://oxalis.br.fgov.be/mirador/ | 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| IIIF Home]] | Back to [[IIIF| IIIF Home]] | ||
Latest revision as of 15:12, 30 September 2022
Part of IIIF Pages
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
_is_displayed_next_to_a_RBGE_specimen_(right).png)
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:
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
