- Introduction to IIIF
- Image API
- Presentation API and IIIF Manifests
- Annotations with IIIF
Workshop Collaborative Notes Files: https://docs.google.com/document/d/1xy8tkK9D7Zwl_QX4HL044V2IvDemV_7z6Dugi2yK3xI/edit
What is IIIF? A bird's eye view
Massive technological redundancy
Prevents connectivity, leading to data redundancy
The Solution Enter IIIF
Two Types of Image Related Data
- Image metadata
- Image presentation data
The IIIF Image API (Image Metadata)
The IIIF Image API is a "rule book" coordinating the description of image metadata and how to request it.
Consumers will want to request...
- The entire image
- A thumbnail of the image
- Part of the image
- A low quality version of the image
Consumers will want to know...
- How big the image is
- Which image sizes are pre-cached
- Which image formats are available
- What are the rights associated with the images
There are lots of ways this information could be communicated.
The IIIF Image API describes a standard so that we can coordinate our efforts and gain the benefits of that coordination.
There are two main things that the IIIF Image API rules govern.
- URI syntax for REQUESTING images and image information.
- For example:
- For example:
- The proper RESPONSE for an image INFORMATION request in an info.json file
Important: A IIIF Image Server does not identify a specific piece of software.
A IIIF Image Server is any software that serves/delivers images while following the above rules.
Therefore, there are lots of IIIF Image Servers. For example:
- Loris written in Python.
- IIPImage Server high performance image server.
- riiif written in Ruby as a Rails engine.
- SIPI IIIFv2 image server written in C++.
- RAIS 100% open source tile server for JP2 images written in Go.
- digilib image server written in Java.
- Cantaloupe - image server written in Java.
- iiif_s3 Ruby library for generating a static IIIF level 0 Image and Presentation API server on Amazon S3.
- Hymir IIIF Server IIIF server written in Java supporting IIIF Image and Presentation API.
- go-iiif IIIF server written in go (fork of greut/iiif).
If we start to imagine how an image viewing application might use this information, we can illustrate it as follows:
The above image shows a viewer using the
info.json file to learn what "tile" sizes have been pre-cached by the server, what size thumbnail has been pre-cached, etc. And it has used the
URI syntax parameters to request different sizes of the image.
The IIIF Presentation API (Image Presentation Data)
We can illustrate the need for a second API, for image presentation data, by filling out the rest of the imagined viewer.
The above image, in blue, shows the kinds of information a viewer might need to create a useful viewing experience.
Image Viewers will want presentation information, such as ...
- Titles for a sequence of images
- Logos of an institution
- Image order
- Several versions of an image
Once more, we need a rule book to coordinate our description of this information.
The most basic concept of the presentation API is the
info.json the manifest contains image presentation data described according to the rules of the IIIF Presentation API.
And once more a IIIF Image Viewer does not indicate a specific piece of software.
Any software that displays images from a IIIF server alongside presentation data contained in a
manifest.json file can be considered a IIIF Image Viewer.
There are lots and you can build your own.
- Universal Viewer is a rich embeddable interface.
- OpenSeadragon has IIIF tile support.
- Leaflet-IIIF lightweight, extensible IIIF image viewer.
- Mirador multi-up workspace. See also Awesome Mirador list.
- Diva.js IIIF image viewer optimized for speed and flexibility.
- IIIFViewer IIIF WebGL / Canvas / DOM mobile-ready fast viewer powered by OpenLayers V3
- Tify is a slim and fast IIIF document viewer built with Vue.js
- IIIF Curation Viewer - A general IIIF viewer with added focus on curation and ordering of cropped IIIF images. Demo
- CanvasPanel is a React library to build IIIF Presentation 3 level viewing experiences including support for annotations.
Other IIIF APIs
50 Consortium members can be seen here
355+ million images
- Text Granularity
Technical Specification Groups
- Software Developers
Content adapted from, re-used, changed, modified similar content produced by the IIIF Community, especially: Jack Reed https://iiif-2-day-workshop.netlify.com/docs/day-one/welcome.html Jason Ronallo https://github.com/IIIF/training/blob/master/intro-to-iiif/SUMMARY.md Jeffrey C. Witt, Jack Reed, Drew Winget, and Rachel Di Cresce https://github.com/IIIF/training/tree/master/iiif-5-day-workshop
IIIF and Digital Editions
The Aspiration for Completeness and Transparency
The technology of the printed book fundamentally permits many things. This makes the homogeneity and regularity of the critical edition, beyond experimental exception cases, all the more remarkable. Today's ideal type of the existing and learned edition is in many ways a product of its technical surroundings. But is also more than anything else mediated through the centuries-long developed media program of the printed book. Accordingly, the scientifically defined goals of the edition are partially sacrificed to the demands of book culture. The 'aim of transparency' as well as the foundational idea, that the tradition must be re-constructible from the edition, would have indeed been technically realizable. By itself the media program of the book culture prioritized the 'usability', the 'affordability', the 'text normality', the 'clarity', the 'simple usability' ahead of the aspiration for completeness, ahead of the corresponding transparency, and ahead of the historicity of the actual tradition recognizing the additional layers of presentation. The uses of images of original manuscripts is a critical component in this effort.
Die Technologie des Buchdrucks erlaubt grundsätzlich vieles. Umso bemer- kenswerter ist die Homogenität und Regelmäßigkeit der kritischen Editionen jenseits der experimentellen Ausnahmefälle. Der heute bestehende und lehrend vermittelte Idealtyp der Edition ist zu weiten Teilen ein Produkt ihrer technischen Umgebung. Sie ist es aber auch und vor allem mittelbar durch das über Jahrhun- derte entwickelte mediale Programm des gedruckten Buches.11 Dabei werden den Vorgaben der Druckkultur die wissenschaftstheoretisch definierten Ziele der Edi- tion teilweise geopfert. Das ,Transparenzgebot‘12 wie auch die Grundidee, dass die Überlieferung aus der Edition rekonstruierbar sein müsste, wären rein technisch im Buchdruck durchaus realisierbar gewesen. Allein das mediale Programm der Buchkultur setzt die ,Handlichkeit‘, die ,Bezahlbarkeit‘, die ,Textnormierung‘, die ,Eindeutigkeit‘, die ,einfache Benutzbarkeit‘ vor den Vollständigkeitsanspruch, vor eine konsequente Transparenz und vor zusätzliche, die Historizität der tat- sächlichen Überlieferung würdigende Präsentationsschichten.
(Patrick Sahle, Zwischen Mediengebundenheit und Transmedialisierung (editio 24, 2010) p. 25-26
Images have an important role to play in the achievement of transparency and completeness.
But there are problems:
- The manuscripts for a given a text are scattered across the globe.
- Institutional image data publication is often varied and idiosyncratic.
As more and more institutions adopt the IIIF standard, the dream of transparency is becoming more and more realizable.
The Aspiration for Scholarly Collaboration over Competition
In the process of creating an edition we are creating lots and lots of auxiliary data highly relevant to image data.
Without a way to share this auxiliary data, it gets re-created.
This redundancy is wasteful.
Rather than collaborating by always building on top of the work that has already been done, scholars are competing to make redundant data.
We need to allow multiple users to work with a common image resources.
IIIF can help make this possible.
Scholars can create auxiliary data and associate it with IIIF image/canvas resources, and then publish that data. Subsequently, an image viewer can retrieve that related data and display it alongside the target resource.