Publicatie:Opzetten IIIF beeldenserver en een eenvoudige webportaal

Dit is de neerslag van een pilootproject dat uitgevoerd werd in het kader van het project Blauwdruk Gedistribueerd Beeldebeheer

Auteur(s)

• Nastasia Vanderperren (PACKED vzw)

Status

• Installatie IIIF beeldenserver: afgewerkt
• Installatie IIIF image viewer: afgewerkt
• Installatie script om TIFF-bestanden naar Pyramid TIFF om te zetten: afgewerkt
• Ontwikkeling catmandu fix om manifests te maken uit een CSV-bestand: afgewerkt
• Metadata verzamelen in CSV: najaar 2017
• Manifests maken met testcollectie KMSKA: najaar 2017
• Uittesten webportaal: vanaf najaar 2017

Probleemstelling

Koninklijke Musea voor Schone Kunsten Antwerpen (KMSKA) beschikt over een grote hoeveelheid beelden die verspreid bewaard worden:

• op een centrale locatie op de server;
• in de mediabank van TMS, het collectiebeheersysteem;
• in mappen van (onderzoeks)projecten waarvoor beelden gemaakt werden;
• in persoonlijke mappen op de server van de medewerkers onder het motto "wat ik zelf bewaar, bewaar ik beter"

Hierdoor is het overzicht zoek en vinden medewerkers geen beelden terug. Om het eindeloos kopiëren onder controle te krijgen en de verspreiding van beelden tegen te gaan, werd er op intranet een formulier gemaakt waarop medewerkers foto's konden aanvragen. De beeldencollectie staat onder de hoede van twee medewerkers, die door de moeilijke doorzoekbaarheid van de collectie, hun dagen vullen met het zoeken naar beelden voor de beeldaanvragers.

Samen met PACKED vzw werd er gezocht naar een oplossing om de toegang tot de beelden te reguleren en de werklast van de twee beeldmedewerkers te verlagen. Omdat KMSKA niet over voldoende budget beschikt voor een DAM-systeem, moest er een andere (tijdelijke) en goedkope oplossing gezocht worden.

Methode

Dit pilootproject had als doel om de werkprocessen m.b.t. beelden binnen KMSKA aan te passen. IIIF werd hiervoor uitgetest.

Doelstellingen bepalen

Er werden op voorhand doelstellingen vastgelegd waaraan de oplossing moest voldoen vanuit de noden van de KMSKA-medewerkers. Dit bakent de mogelijkheden af en had als resultaat dat er meer gericht naar een oplossing gezocht kon worden.

De doelstellingen voor de oplossing waren:

• KMSKA-medewerkers vinden zelf beelden op basis van inventarisnummer, kunstenaar en/of titel;
• KMSKA-medewerkers kunnen de beelden interpreteren door aanwezigheid van identificerende metadata;
• KMSKA-medewerkers kunnen beelden zien zonder ze manueel te moeten openen
• KMSKA-medewerkers kunnen via de applicatie zelf geen beelden opslaan om ze in een eigen persoonlijke map te bewaren
• KMSKA-medewerkers kunnen zoomen op beelden
• KMSKA-medewerkers kunnen in de applicatie verschillende beelden van kunstwerken met elkaar vergelijken.

IIIF als oplossing?

Er werd geopteerd om hiervoor IIIF uit te testen. IIIF bestaat uit een aantal API's voor de uitwisseling van beelden. De gemeenschap achter IIIF - een consortium van (universiteits)bibliotheken, musea, archiefinstellingen en software-ontwikkelaars - moedigen tevens de ontwikkeling aan van beeldenservers en viewers die de API's geïmplementeerd hebben. IIIF is een universeel protocol. Dit betekent dat beelden die bewaard worden op een IIIF-server geopend kunnen worden in iedere viewer die IIIF geïmplementeerd heeft. Dit heeft als voordeel dat in IIIF-viewers verschillende beelden met elkaar vergeleken kunnen worden. Het bestaat uit vier protocols waarvan de IIIF Image API en de IIIF Presentation API de belangrijkste zijn.

• IIIF Image API is verantwoordelijk voor het aanleveren van beelden op basis van een URI. Via de URI kunnen de grootte, uitsnijding, kwaliteit en bestandsformaat van het opgevraagd beeld verder gespecificeerd worden.
• IIIF Presentation API voorziet de nodige metadata om een beeld en de context van het beeld begrijpbaar te maken. Met de IIIF Presentation API kunnen verwante beelden met elkaar gelinkt worden, zodat je alle beelden van een manuscript, of de verschillende zichten van een kunstwerk, via één digitaal object kunt opvragen.

In Vlaanderen hebben de Universiteitsbibliotheek van Gent en LIBIS reeds beelden ontsloten via IIIF.

Na een korte bestudering van de protocols en de demo's op de IIIF-website, kwamen we tot de vaststelling dat de protocols en de ontwikkelde software volgende doelstellingen waarmaken.

• KMSKA-medewerkers kunnen de beelden interpreteren door aanwezigheid van identificerende metadata: OK
• KMSKA-medewerkers kunnen beelden zien zonder ze manueel te moeten openen: OK
• KMSKA-medewerkers kunnen zoomen op beelden: OK
• KMSKA-medewerkers kunnen in de applicatie verschillende beelden van kunstwerken met elkaar vergelijken: OK

Doordat de applicaties gratis en open source zijn, leek dit voldoende om voor deze case IIIF uit te testen.

Om een IIIF-service in KMSKA te implementeren, werd de Quick Start Guide van IIIF gevolgd. Er werd afgesproken om te starten met een beperkte groep van beelden die allemaal de CC0-licentie hebben. Beelden van events (schadeclaims, openingen tentoonstellingen, etc.) werden buiten de scope gehouden. Indien de test positief geëvalueerd wordt, kan de collectie beelden uitgebreid worden.

Beeldenserver opzetten

Stap 1 bestond uit het opzetten van een beeldenserver die IIIF Image API v2.0 ondersteunt. Dit betekende dat de server beelden moet kunnen aanleveren zoals ze gespecifieerd werd in API: {protocol}://{domeinnaam}/{servernaam}/{identifier_beeld}/{regio}/{afmeting}/{rotatie}/{kleur_beeld}.{extensie}.

Voor KMSKA zou dit bijvoorbeeld: https://www.kmska.be/iiif/afbeelding1/full/full/0/default.jpg kunnen zijn.

De IIIF Quick Start Guide raadt volgende servers aan om te installeren wanneer je start met IIIF:

• Loris: Een open source en gratis beeldenserver die geïnstalleerd kan worden op Linux (Ubuntu, Red Hat en CentOS) en die beeldbestanden aanvaardt in JPEG, JPEG2000 en TIFF.
• IIPImage Server: Een open source en gratis beeldenserver die geïnstalleerd kan worden op verschillende Linuxdistributies, Windows en Mac OS X. Het aanvaardt beeldbestanden in JPEG2000 of TIFF.

De IIPImage Server is een officieel package van de Linuxdistributies Ubuntu, Debian, Fedora, Red Hat en CentOS en is bijgevolg op basis van een paar commando's te installeren. Daarom koos KMSKA voor deze beeldenserver.

Na intallatie en configuratie van de server, werd de server gevalideerd via de IIIF Image API Validator.

TIFF omzetten naar Pyramid TIFF

Om het inzoomen op de beelden via de IIPImage Server mogelijk te maken, moesten de TIFF-bestanden omgezet worden naar een bestandsformaat waarin verschillende resoluties van een beeld bewaard kunnen worden. Indien dit bij hogeresolutiebeelden niet gebeurt, duurt het lang eer een beeld geladen kan worden. Pyramid TIFF is zo'n multiresolutieformaat. In een Pyramid TIFF worden verschillende JPEG-tiles van verschillende groottes bewaard. Zo kan de browser even snel een beeld op 100% als een klein detail waarop diep ingezoomd wordt ophalen.

KMSKA intalleerde een script op de beeldenserver zodat ieder beeld dat op de server geplaatst wordt, automatisch naar Pyramid TIFF omgezet werd. ImageMagick werd hiervoor als tool gebruikt. Met volgend commando in de command line of in een script kan een TIFF omgezet worden:

convert s.tif -define tiff:tile-geometry=256x256 -compress jpeg 'ptif:o.tif'

• s.tif = naam bronbestand
• o.tif = naam outputbestand
• ptif = bestandsformaat wordt als pyramid tiff gespecifieerd
• 256x256 = de tile-grootte in pixels

Viewer opzetten

Vervolgens diende een viewer geïnstalleerd te worden die de IIIF Presentation API geïmplementeerd heeft. In de Quick Start Guide werden volgende viewers aangeraden:

• OpenSeaDragon: een gratis en open source viewer die het mogelijk maakt om in te zoomen op hogeresolutiebeelden.
• IIPMooViewer: een gratis en open source viewer die het ook mogelijk maakt om in te zoomen op beelden. Het is gemaakt door de ontwikkelaars van IIPImage Server.
• Mirador: een gratis en open source viewer waarin je eveneens kan inzoomen op beelden. Mirador kan gebruikt worden als werkstation waarin je verschillende beelden met elkaar kan vergelijken. Beelden kunnen tevens gedraaid, helderder, constrastrijker, zwart-wit, etc. getoond worden. Het toont ook de beschrijvende metadata die bij het beeld horen

Verschillende beelden kunnen vergelijken en kunnen identificeren op basis van beschrijvende metadata waren twee vereisten van KMSKA. Bijgevolg werd er voor Mirador gekozen.

Manifests maken

Om de beelden die opgeladen werden in de beeldenserver te tonen in de viewer, moest de specificatie van de IIIF Presentation API gevolgd worden. Deze biedt een structuur en lay-out aan om de beelden en metadata van een object op een standaardmanier beschikbaar te stellen. Een object kan bestaan uit verschillende beelden, bijvoorbeeld een voor- en achterkant, verschillende zichten, detailbeelden, opeenvolgende pagina's, etc. De voornaamste doelstellingen van de Presentation API zijn een volgorde aanbieden voor die verschillende zichten, een link te leggen met de beelden die via de Image API ontsloten worden, en beschrijvende informatie voorzien zodat een gebruiker weet wat hij ziet. De informatie wordt gecodeerd via JSON-LD en gebruikt het Shared Canvas datamodel. Het Shared Canvas datamodel biedt een linked datamodel aan om digitale representaties van fysieke objecten te beschrijven.

De IIIF Presentation API bestaat uit een aantal basistypes:

• een manifest: dit is een JSON-bestand dat een algemene beschrijving aanbiedt van de structuur en eigenschapen van de digitale representatie van een object. Het biedt alle informatie aan de viewer aan om de digitale content te presenteren aan een gebruiker, zoals de titel van het object. Ieder manifest beschrijft de presentatie van één enkel object, zoals een schilderij, standbeeld, foto, etc.
• een sequence: dit legt de volgorde van de beelden vast. Ieder manifest heeft verplicht één sequence, maar kan ook verschillende sequences bevatten.
• een canvas: dit is een virtuele container die één pagina of beeld representeert. Het canvas is zoals een wit blad, waar een beeld op geschilderd wordt en dat ook beschrijvende informatie over het beeld kan bevatten. Iedere sequence bevat verplicht minstens één canvas.
• content: beelden of andere digitale objecten die bij het canvas horen. Een canvas hoeft niet verplicht een beeld te bevatten.

Naast deze basistypes vereist de Presentation API slechts een beperkt aantal verplichte metadata:

• een id van het object;
• een label van het object;
• een label voor ieder beeld dat in het canvas vastgelegd wordt.

Daarnaast zijn er ook nog metadata voorzien om een beschrijving van het kunstwerk toe te voegen, rechtenlicenties, attributie, verwante items, etc. Daarnaast kan er naar wens nog extra metadata toegevoegd worden. Op deze manier kan een manifest voorzien worden van een rijke beschrijving.

Metadata vastleggen

Er werd met KMSKA afgesproken om ieder manifest te voorzien van een id, een label, een rechtenlicentie (voorlopig enkel CC0), een link naar de PID van het kunstwerk, een link naar de afbeeldingen volgens de IIIF Image API en een label voor ieder beeld. Omdat je in Mirador beelden kunt filteren en zoeken op basis van het label van het manifest (kunstwerk), werd afgesproken om het label samen te stellen uit inventarisnummer, kunstenaar en titel kunstwerk. Er werd verwacht dat op deze manier de meeste KMSKA-medewerkers beelden konden vinden.

Het meeste eenvoudige was om deze gegevens te verzamelen in een CSV en de vereiste gegevens te exporteren uit het collectiebeheersysteem TMS.

CSV omzetten naar manifest JSON-bestand

De gegevens uit de CSV moesten omgezet worden naar een manifest JSON-bestand. Hiervoor werd Catmandu uitgetest. KMSKA is partner in het Datahub-project, waarvoor ook Catmandu gebruikt wordt, en heeft om deze reden zelf Catmandu draaien op een server. Catmandu is een tool waarmee je onder meer data kunt omzetten naar een andere codering. Zo kan het CSV omzetten naar JSON. Bovendien beschikt Catmandu over de Fix-taal waarmee het mogelijk is om data te manipuleren en aan te passen.

PACKED vzw ontwikkelde een Catmandu fix om de gegevens uit de CSV-velden om te zetten tot een JSON-bestand die voldeed aan de vereisten uit de Presentation API. Foutjes in de fix werden opgespoord door de gecreëerde manifests te valideren met de IIIF Presentaton API Validator. De fix en documentatie over de opbouw en het gebruik ervan zijn te raadplegen op Github.

De fix werkte en zette testbestanden in CSV om naar IIIF manifests. De manifests konden geopend worden in Mirador.

De gegeneerde manifests konden toegevoegd worden aan Mirador

Afbeeldingen van een kunstwerk konden gezocht worden op label (inventarisnummer, kunstenaar en titel

Overzicht van de beelden van een manifest. Het label van iedere afbeelding is zichtbaar, waardoor ieder beeld te identificeren is.

Bekijken van een afbeelding van een manifest.

Op de beelden kan ingezoomd worden. Beschrijvende metadata uit het manifest wordt in de zijbalk getoond.

IIIF-manifests van andere instellingen die via hun beeldenserver ontsloten worden, kunnen opgeladen worden in Mirador en vergeleken worden met de eigen beelden.

CSV van KMSKA omzetten naar individuele manifest bestanden

Deze actie zal gestart worden in oktober 2017.

Uitrol in KMSKA

Deze actie zal gestart worden in najaar 2017.

Resultaten

• IIIF toegang tot beelden KMSKA
• Technische documentatie om via Catmandu een manifest te maken
• Draaiboek voor het opzetten van een IIIF service.