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

smon

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:

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:

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

https://github.com/dainst/iiif_image_plug

3 comments

#library #plug #image #vix #libvips

15 643 3

2026-01-19 16:05:37 UTC

Showing Posts 1 to 3

Show Best Posts
Show All (oldest first)
Show All (newest first)

smon

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

Post #1

smon

As hinted in the last update, I rewrote the library utilizing the __using__ makro, which feels way better from a usability standpoint: Overview — IIIFImagePlug v1.0.1

Please poke at it and see if anything breaks or is missing.