iiif_image_plug - An Elixir Plug implementing the IIIF image API specification.

Your Libraries & OS Mentoring Libraries
, , ,
1

The International Image Interoperability Framework describes itself:

IIIF is a set of open standards for delivering high-quality, attributed digital objects online at scale. It’s also an international community developing and implementing the IIIF APIs. IIIF is backed by a consortium of leading cultural institutions.

This plug implements the most basic of these standards: The image API (version 3). The official IIIF documentation does a good job of describing the API in detail, so here just a small example.

The basic API syntax is

{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}

An example based on the plug’s sample image in development would be:

http://127.0.0.1:4000/bentheim.tif/full/max/0/default.jpg

Which would give me a jpg (see the format) version of the original tif:

bentheim_full
bentheim_full1200×912 100 KB

Now I can change the region, size, rotation, quality and format parameters in my query. The following query will:

  • select a part of the image
    – left: 700 pixel
    – top: 500 pixel
    – width: 520 pixel
    – height: 520 pixel
  • scale the image to 89% of its original size
  • flip the image (!) and then rotate it by 53°
  • make the image bitonal
  • return the image as png
http://127.0.0.1:4000/bentheim.tif/700,500,520,520/pct:89/!53/bitonal.png

The result:

example_manipulation
example_manipulation648×648 6.9 KB

There exist several generic Javascript IIIF viewers that utilize this API to allow for optimized viewing (dynamic loading of parts of the image data based on zoom level/viewport).

WebGIS Javascript libraries like leaflet or OpenLayers support IIIF in one way or the other.

The image processing is handled by libvips via Vix.

See iiif_image_plug | Hex

13 Likes
2

The library is now at version 0.5.0, there is one major question I am still unsure about. Maybe somebody here has some insight:

I have currently defined callback functions as plug parameters to allow the library users’ to inject some of their logic. The primary example would be the identifier_to_path_callback, which allows the plug to construct a filesystem path for a given identifier.

Is this the best way to do it? It seems to me that callbacks are a black box for language servers, you will not get any feedback if your provided callback does implement arity, parameters or return values expected by the plug.

Is meta programming the way to go? The counter argument would be: The callbacks are currently quite simple, so meta programming could introduce quite some complexity on the plug’s code side that is not worth the trade off.

I am currently experimenting with the library while rewriting publication platform for archaeological excavations. This is still in an alpha, besides the IIIF stuff I am also experimenting with LiveView Hooks for OpenLayers, and other stuff - so this link might not work from time to time: https://publication.field.test.idai.world/projects/bourgou/2024-05-14/de/86787076-5253-4071-b1ad-b2644506974d

The platform itself is open source: GitHub

1 Like