The IIIF Image API
•Transferir como PPTX, PDF•
0 gostou•229 visualizações
A presentation given at the International Image Interoperability Framework event held at Ghent University, Belgium on December 8, 2015. Simeon Warner Cornell University
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a The IIIF Image API
Semelhante a The IIIF Image API (20)
Mais de IIIF_io
Mais de IIIF_io (20)
Último
Último (20)
The IIIF Image API
- 1. 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,...
- 2. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 The Problem
- 3. 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
- 4. 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
- 5. 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
- 6. 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
- 7. 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
- 8. 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!
- 9. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 {id}/full/400,/0/default.jpg
- 10. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 {id}/3930,60,1230,3600/400,/0/default.jpg
- 11. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 {id}/3930,60,1230,3600/400,/90/default.jpg
- 12. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 {id}/3930,60,1230,3600/400,/90/gray.jpg
- 13. 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.
- 14. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 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 } ] }
- 15. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 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" ] }
- 16. 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/
- 17. 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
- 18. 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
- 19. IIIF: Access to the World's Images – Ghent, Belgium, 2015-12-08 Thank you! http://iiif.io/api/image/2.0/
Notas do Editor
- 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