IIIF

IIIF (International Image Interoperability Framework, gesprochen „Triple-I-F”) ist eine Suite von HTTP-APIs für die interoperable Auslieferung und Präsentation von Bildern — und seit Version 3 auch von Audio- und Video-Material. Vom IIIF-Konsortium (gegr. 2015, ~70 Mitgliedsinstitutionen) entwickelt, ist IIIF heute der De-facto-Standard für die Online-Präsentation von Handschriften, Drucken, Karten, Kunstwerken und audiovisuellen Beständen in Bibliotheken, Archiven und Museen.

Der Kern-Versprechen: „zoomable, interoperable, citable, annotatable” — Bilder einer Institution können in einem Viewer einer anderen Institution geladen, mit Annotationen einer dritten Institution überlagert und mit stabilen URLs zitiert werden.

Die fünf APIs

API	Aufgabe
Image API	Auslieferung von Bild-Derivaten on-the-fly (Region, Grösse, Rotation, Format)
Presentation API	Beschreibung des „Objekts” (Buch, Manuskript, Sammlung) als JSON-LD-Manifest
Search API	Volltextsuche innerhalb eines Manifests
Authentication API	Zugriffskontrolle für geschützte Ressourcen
Change Discovery API	Tracking von Änderungen an Beständen für Aggregator-Indexierung

In der Praxis sind Image API + Presentation API das Fundament; die übrigen drei sind je nach Use Case optional.

Image API — URL als Bild-Manipulation

Die Image API kodiert die gewünschte Bild-Operation direkt in der URL:

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

Segment	Beispiele
region	`full` · `square` · `125,15,120,140` (x,y,w,h in px) · `pct:10,10,80,80`
size	`max` · `512,` (Breite, Höhe proportional) · `,512` · `512,512` (exakt) · `pct:50`
rotation	`0` · `90` · `!0` (gespiegelt)
quality	`default` · `color` · `gray` · `bitonal`
format	`jpg` · `png` · `tif` · `webp` · `gif`

Konkrete URLs:

# Vollbild, maximale Grösse
https://example.org/iiif/3/ms-cb-127/full/max/0/default.jpg

# 512 px breit, proportional skaliert
https://example.org/iiif/3/ms-cb-127/full/512,/0/default.jpg

# Ausschnitt 1000×1000 px ab Pixel (200,200), als 256×256 Thumbnail
https://example.org/iiif/3/ms-cb-127/200,200,1000,1000/256,256/0/default.jpg

# 90° rotiert, als PNG
https://example.org/iiif/3/ms-cb-127/full/max/90/default.png

Jeder Image-API-Endpunkt liefert unter /info.json einen Service-Descriptor mit verfügbaren Auflösungs-Kacheln, unterstützten Formaten und Profilen — der „Pakt” zwischen Server und Viewer.

Presentation API — das Manifest

Ein Manifest ist ein JSON-LD-Dokument, das ein logisches Objekt (Buch, Manuskript, Skulptur, Tonband) beschreibt. Es ist die zitierbare Repräsentation des Objekts im IIIF-Universum.

Hierarchie in V3:

Manifest
  └── items[] (Canvas)              eine Seite / Ansicht
       └── items[] (AnnotationPage)
            └── items[] (Annotation, motivation: "painting")
                 └── body (Image / Sound / Video)  → Image-API-Service

Eine Canvas ist die virtuelle „Leinwand” einer Seite mit fixer Pixel-Höhe/Breite; eine Annotation mit motivation: "painting" malt einen konkreten Bild- (oder AV-)Inhalt auf diese Leinwand. Andere Annotation-Motivationen (commenting, tagging, transcribing) erlauben Overlays wie Transkriptionen oder Markierungen — interoperabel über Institutionsgrenzen.

Minimal-Manifest in V3 (eine Seite, ein Bild):

{
  "@context": "http://iiif.io/api/presentation/3/context.json",
  "id": "https://example.org/iiif/ms-cb-127/manifest.json",
  "type": "Manifest",
  "label": { "de": ["Codex CB 127 — Beispielmanuskript"] },
  "metadata": [
    { "label": { "de": ["Signatur"] }, "value": { "de": ["CB 127"] } },
    { "label": { "de": ["Datierung"] }, "value": { "de": ["um 1450"] } }
  ],
  "rights": "https://creativecommons.org/licenses/by/4.0/",
  "items": [
    {
      "id": "https://example.org/iiif/ms-cb-127/canvas/1",
      "type": "Canvas",
      "height": 4000,
      "width": 3000,
      "items": [{
        "id": "https://example.org/iiif/ms-cb-127/canvas/1/page",
        "type": "AnnotationPage",
        "items": [{
          "id": "https://example.org/iiif/ms-cb-127/canvas/1/anno",
          "type": "Annotation",
          "motivation": "painting",
          "body": {
            "id": "https://example.org/iiif/3/ms-cb-127/full/max/0/default.jpg",
            "type": "Image",
            "format": "image/jpeg",
            "width": 3000,
            "height": 4000,
            "service": [{
              "id": "https://example.org/iiif/3/ms-cb-127",
              "type": "ImageService3",
              "profile": "level2"
            }]
          },
          "target": "https://example.org/iiif/ms-cb-127/canvas/1"
        }]
      }]
    }
  ]
}

Versionen

V1 (2012) — nur Image API, experimentell
V2.x (2014–2017) — Image + Presentation API stabil; Microservice-tauglich; weite Verbreitung
V3 (2020) — vereinfachte Struktur, AV-Support (Sound, Video), W3C-Web-Annotation als Annotation-Modell, Mehrsprachigkeit als First-Class-Feature
V2 und V3 koexistieren in der Praxis. Viele Bestände sind weiterhin V2; Neuprojekte sollten V3 wählen. Viewer wie Mirador 3 und Universal Viewer unterstützen beide Versionen.

Die wichtigsten Änderungen V2 → V3:

V2	V3
`sequences[].canvases[]`	direkt `items[]` (Canvas)
`images[]` mit `motivation: sc:painting`	`items[]` (AnnotationPage → Annotation)
`@id`, `@type`, `@context`	`id`, `type` (nur `@context` bleibt)
`label`, `description` als String	strukturiertes `label` mit Sprach-Codes
`attribution`	`requiredStatement`
`license`	`rights` (mit erlaubten URI-Patterns)

Server-Implementierungen

Server	Sprache	Eigenschaft
Cantaloupe	Java	Modulare Quellen (Filesystem, S3, HTTP), Caches, leichtgewichtig
IIPImage	C++	Reife C++-Lösung mit hoher Performance, V2-fokussiert
Loris	Python	Klein, einfach, V2
iipsrv-openseadragon	C++	Klassiker, oft mit JPEG2000-Quelldateien
SimpleTiles / SipiServer	C++	Forschungsprojekte (SwissArt, NIE-INE)

Die meisten Server konsumieren als Quelle JPEG2000 (.jp2) oder Pyramid TIFF (.tif) — beides Formate mit schneller Region-/Auflösungs-Selektion ohne vollständigen Decode.

Viewer

Viewer	Stärken
Mirador 3	Workspaces mit mehreren Manifesten parallel, Annotation-Editor; Forschungs-orientiert
Universal Viewer	Single-Object-Fokus, sauber für Endnutzer-Sites
Tify	Schlank, deutsche Wurzeln, fokussiert auf einzelne Manifeste
Clover	Speziell für AV-Manifeste (V3)
Diva.js	Performance-fokussiert für sehr lange Dokumente

OpenSeadragon ist die Tile-Rendering-Engine, die viele dieser Viewer intern nutzen.

Annotationen

In V3 sind Annotationen vollwertige W3C-Web-Annotation-Objekte. Damit lassen sich auf einer Canvas auflagern:

Transkriptionen (motivation: "supplementing" oder "commenting")
Tags / Schlagwörter (motivation: "tagging")
Bounding Boxes mit Kommentar (target als Fragment-Selector #xywh=...)
Verweise auf andere Manifeste (Cross-Linking)

Annotationen können bei einer anderen Institution liegen als die Bilder selbst — das ist der „interoperable” Teil von IIIF: Forschende können einer Sammlung Annotationen hinzufügen, ohne Schreibrechte auf den Original-Server zu haben.

Häufige Patterns

Range — eine Untermenge von Canvases als Kapitel oder Inhaltsverzeichnis modellieren
Choice — alternative Bilder pro Canvas (z. B. Tageslicht / UV / Infrarot)
Collection — ein Manifest, das andere Manifeste gruppiert (Sammlungs-Hierarchie)
navDate — Datum auf Canvas-/Manifest-Ebene zur chronologischen Sortierung in Aggregator-Viewern

Verhältnis zu anderen Standards

METS — METS und IIIF-Manifest decken zum Teil überlappende Bedürfnisse ab. METS ist tiefer (kann Erhaltungs-Metadaten via PREMIS, Strukturkarten, Verwaltungs-Metadaten); IIIF-Manifest ist schlanker und web-orientiert. Häufig wird METS intern, IIIF nach aussen verwendet.
Dublin Core — IIIF nutzt keinen festen Metadaten-Standard; das metadata-Array ist freier Text. Dublin-Core- oder MODS-Felder können dort hineingespiegelt werden.
TEI — Wenn Transkriptionen in TEI vorliegen, können sie als IIIF-Annotationen auf die jeweilige Canvas-Region gemappt werden.
OAI-PMH — als Discovery-Mechanismus für IIIF-Manifeste; alternativ die IIIF Change Discovery API.
CIDOC-CRM — kann als semantischer Layer über IIIF-Bestände gelegt werden (Object → IIIF-Repräsentation).
schema.org — Manifest kann optional schema: -Properties einbetten für SEO/Aggregatoren.

Aggregatoren und prominente Adopter

Viele nationale und institutionelle Portale exponieren ihre Digitalisate als IIIF:

e-codices (Schweizer Handschriftenportal) und e-rara / e-manuscripta
e-newspapers Schweiz und DigiVatLib (Vatikan)
Gallica (BnF), British Library, Bodleian Libraries, Library of Congress
Smithsonian, Yale, Stanford, Harvard Art Museums
Deutsche Digitale Bibliothek und Europeana (mit IIIF-Layer über aggregierten Beständen)

Werkzeuge für den Alltag

Mirador 3 — der Schweizer-Taschenmesser-Viewer für Forschung und Vergleich
Manifest Editor (Digirati) — Web-basierter Editor für Presentation-API-Manifeste
biiif — CLI, das aus einer Verzeichnisstruktur ein Manifest generiert
iiif-prezi3 (Python) — Library für die programmatische Manifest-Erstellung in V3
iiif-validator — Schema- und Profil-Validierung von Image-API-Endpunkten und Presentation-API-Manifesten

Häufige Fallen

Bildgrösse vs. Service-Auflösung: das width/height im Manifest muss der vollen Auflösung des Image-Service entsprechen (nicht der ausgelieferten JPEG-Grösse), sonst rechnet der Viewer Koordinaten falsch um.
CORS: Image- und Presentation-API müssen Access-Control-Allow-Origin setzen, sonst können Cross-Origin-Viewer das Manifest nicht laden.
Profile-Versions-Mismatch: ein V3-Manifest, das auf einen V2-Image-Service verweist (ImageService2 statt ImageService3), funktioniert — aber service[].profile muss korrekt sein.
Sprach-Codes: in V3 sind Sprach-Codes in label/metadata Pflicht. "label": "Beispiel" ist V2-Stil; in V3 gilt "label": { "de": ["Beispiel"] }.
Mixed Content: HTTPS-Manifest, das auf HTTP-Bilder verweist, wird im Browser blockiert.