A presentation given at the International Image Interoperability Framework event held at Ghent University, Belgium on December 8, 2015.
Simeon Warner
Cornell University
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
The IIIF Image API
http://iiif.io/api/image/2.0/
Simeon Warner (Cornell University)
With lots of help (& slides) from Jon Stroop, Rob
Sanderson, Michael Appleby, Tom Crane,...
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
The Problem
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
Without Standards We Have Silos
Application A
Server A
Application B
Server B
Application C
Server C
Application D
Server D
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
Technology Becomes Interchangeable
Application A
Server D
Application B
Server C Server B
Application C
Server A
Application D
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
Resources Become Shareable
Application A
Server D
Application B
Server C Server B
Application C
Server A
Application D
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
The Solution... IIIF Image API
Image API v2.0
Draft 2014-06
Community review
Released 2014-08
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
Syntax
(Just Enough) Technical Metadata
The Image
Server Capabilities
http(s)://{server}{/prefix}/{id}/info.json
http(s)://{server}{/prefix}/{id}/{region}/{size}/{rotation}/{quality}.{fmt}
http://iiif.io/api/image/2/level2.json
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
{id}/full/full/0/default.jpg
5204 x 7200
pixels
/full/full/ not
practical for
all images!
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
{id}/full/400,/0/default.jpg
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
{id}/3930,60,1230,3600/400,/0/default.jpg
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
{id}/3930,60,1230,3600/400,/90/default.jpg
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
{id}/3930,60,1230,3600/400,/90/gray.jpg
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
{id}/full/150,/0/default.png
• png supports transparency
• used for thumbnails etc.
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
level0 – static files
•IIIF supports static files, pre-generated tiles
•Can still do pan & zoom
•Can still have a set of thumnail sizes
•Image Information (info.json) lets client know
what is available
Demo:
http://zimeon.github.io/iiif-static-mandlebrot/
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
Implementations
Servers Clients
digilibCONTENTdm
OpenSeadragon
IIPMooViewer
OpenLayers
Leaflet-IIIF
+Applicationsbasedonthese
RAIS Image Server
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
v2.1 nearing final draft
No breaking changes
Clarity++
Adds attribution,
license and logo
Adds square region
Tie to authentication
IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08
Thank you!
http://iiif.io/api/image/2.0/
Editor's Notes
As you've heard already IIIF has published two API specifications:
The Image API: for getting at images and relevant metadata
The PresentationAPI: images with relevant descriptive properties, in the context of related content included text transcriptions, annotation, and other related images.
What is the Problem that the Image API tries to solve?
The problem is that we're all locked into our image delivery systems, and because of this, we can't share our content or choose different tools.
Let me explain.
Without standards we can only have closed systems, servers clients that understand a particular, unique protocol.
The Image API makes technologies interchangeable, giving us choices between different technologies in the different roles within our application stack
This allows us to choose:
Best of breed tech (server and client)
Servers that play well in existing environment/infrastructure
Clients that are most suitable to your resources and/or users
Finally, if it isn’t obvious, this also means we can share resources, as clients can speak to multiple servers; this is the heart of the IIIF vision.
[Bring up spec briefly: http://iiif.io/api/image/2.0/ ]
We’re not going to work through this line by line; I’m going to give you an overview by means of a demo.
We ultimately decided that the server needed three broad categories of service:
The image
Technical metadata
A way to express the server's capabilities (what can this server do?)
The first two services are defined as syntaxes for that software and humans can build. Server capabilities are published on the IIIF website and can be linked to, as I'll demonstrate in a few minutes
For the image service, we ultimately decided that region, size, rotation, quality, and format are in scope, but that things like color management and format-specific details like compression are out. I’ll illustrate these in a demo momentarily
For the technical metadata service, all elements should be machine-extractable, and there should be just enough to drive a rich client, e.g. qualities available, image size, tile size, and in case the server doesn’t support arbitrary sizes, what sizes are available.
These URIs demonstrate just a few of the ways in which the Image API allows you to manipulate images
While one can carefully craft URIs (as I'll do while demonstrating), it is generally expected and intended that URIs will be built using rich web-clients, some of which we’ll demonstrate a bit later on.
That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful, and they make web caches more efficient
Actual image is 5204 x 7200; this is scaled to fit the slide
We don't expect humans to construct this, but this gives you a nice, clean, reusable (cacheable) URI
Previously select region rotated by 90 degrees, can also mirror
You can't tell it's a png, but trust me….
For the technical metadata service, all elements should be machine-extractable, and there should be just enough to drive a rich client, e.g. qualities available, image size, tile size, and in case the server doesn’t support arbitrary sizes, what sizes are available.
## Go to live demo, during which, be careful to point out:
While one can carefully craft URIs (as I'll do while demonstrating), it is generally expected and intended that URIs will be built using rich web-clients, some of which we’ll demonstrate a bit later on.
That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful, and they make web caches more efficient
For the technical metadata service, all elements should be machine-extractable, and there should be just enough to drive a rich client, e.g. qualities available, image size, tile size, and in case the server doesn’t support arbitrary sizes, what sizes are available.
## Go to live demo, during which, be careful to point out:
While one can carefully craft URIs (as I'll do while demonstrating), it is generally expected and intended that URIs will be built using rich web-clients, some of which we’ll demonstrate a bit later on.
That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful, and they make web caches more efficient
Implementations ... and here I’m only mentioning the base level image viewer clients and not the growing number of applications build using these. For example, both Mirador and the Universal Viewer are based on OpenSeadragon