Introduction to the IIIF Image API
•Download as PPTX, PDF•
3 likes•840 views
An introduction to the IIIF Image API for Sharing Images of Global Cultural Heritage at the National Gallery of Art, 5 May 2015.
More Related Content
Similar to Introduction to the IIIF Image API
Similar to Introduction to the IIIF Image API (20)
More from Jon Stroop
Recently uploaded
Recently uploaded (20)
Introduction to the IIIF Image API
- 1. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 The IIIF Image API http://iiif.io/api/image/2.0/
- 2. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 The Problem
- 3. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Without Standards We Have Silos Application A Server A Application B Server B Application C Server C Application D Server D
- 4. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Technology Becomes Interchangeable Application A Server D Application B Server C Server B Application C Server A Application D
- 5. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Resources Become Shareable Application A Server D Application B Server C Server B Application C Server A Application D
- 6. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Syntax
- 7. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 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
- 8. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Syntax • Full Size, Whole Image • 400 Wide, Whole Image • 400 Wide, Region • 400 Wide, Region, Rotated • 400 Wide, Region, Rotated, Grayscale • Thumbnail, as a PNG
- 9. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 info.json { "@context" : "http://iiif.io/api/image/2/context.json", "@id" : "http://libimages.princeton.edu/loris2/pudl0130%2F8555444%2F02%2F00000007.jp2", "height" : 7200, "width" : 5204, "profile":[ "http://iiif.io/api/image/2/level2.json", { "supports" : [ "canonicalLinkHeader", "profileLinkHeader", "mirroring" ], "qualities" : [ "default", "bitonal", "gray", "color" ], "formats" : [ "jpg", "png", "gif", "webp" ] } ], "protocol" : "http://iiif.io/api/image", "tiles" : [{ "width" : 1024, "scaleFactors" : [ 1, 2, 4, 8, 16, 32, 64, 128 ] }], "sizes":[ { "width" : 41, "height" : 57 }, { "width" : 82, "height" : 113 }, { "width" : 163, "height" : 225 }, { "width" : 326, "height" : 450 }, { "width" : 651, "height" : 900 }, { "width" : 1301, "height" : 1800 }, { "width" : 2602, "height" : 3600 }, { "width" : 5204, "height" : 7200 } ] }
- 10. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 leveln.json { "@context" : "http://iiif.io/api/image/2/context.json", "@id" : "http://iiif.io/api/image/2/level2.json", "@type" : "iiif:ImageProfile", "formats" : [ "jpg", "png" ], "qualities" : [ "default", "bitonal" ], "supports" : [ "baseUriRedirect", "cors", "jsonldMediaType", "profileLinkHeader", "regionByPx", "sizeByH", "sizeByPct", "sizeByW", "regionByPct", "rotationBy90s", "sizeByForcedWh", "sizeByWh" ] }
- 11. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Implementations Servers Clients djatoka digilibCONTENTdm OpenSeadragon IIPMooViewer OpenLayers Leaflet-IIIF
- 12. @jpstroop Sharing Images of Global Cultural Heritage, NGA, 5 May 2015 Thank You! http://iiif.io/api/image/2.0/ Jon Stroop Princeton University Library jpstroop@gmail.com @jpstroop
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 worked very hard to determine what the most useful information, parameters services are. There have been other attempts at this in the past, but the results were generally too complicated, too server-specific, or included a lot of detail or superfluous syntax that UI designers didn't want to have to know.
- 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 slid
- * This is smaller than 400 wide, to fit the slide
- We don't expect humans to do this, but this gives you a nice, clean, reusable (cacheable) URI
- * 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
- 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.