The IIIF Image API

26 de May de 2016
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
The IIIF Image API
1 de 19

Más contenido relacionado

Similar a The IIIF Image API

Introduction to the IIIF Image APIIntroduction to the IIIF Image API
Introduction to the IIIF Image APIJon Stroop
Diffin NLM Digital CollectionsDiffin NLM Digital Collections
Diffin NLM Digital CollectionsNational Information Standards Organization (NISO)
apidays LIVE Helsinki & North 2022_Apps without APIsapidays LIVE Helsinki & North 2022_Apps without APIs
apidays LIVE Helsinki & North 2022_Apps without APIsapidays
IIIF DevelopmentIIIF Development
IIIF DevelopmentKaren Estlund
IIIF presentation - EuropeanaTech 2015IIIF presentation - EuropeanaTech 2015
IIIF presentation - EuropeanaTech 2015Petr Pridal
Bringing IIIF to the DSpace communityBringing IIIF to the DSpace community
Bringing IIIF to the DSpace community4Science

Más de IIIF_io

Open Images for IIIFOpen Images for IIIF
Open Images for IIIFIIIF_io
IIIF and the National Library of WalesIIIF and the National Library of Wales
IIIF and the National Library of WalesIIIF_io
IIIF Annotation and DiscoveryIIIF Annotation and Discovery
IIIF Annotation and DiscoveryIIIF_io
Embedr.eu & OmekaEmbedr.eu & Omeka
Embedr.eu & OmekaIIIF_io
Mirador: A Cross-Repository Image Comparison and Annotation ToolMirador: A Cross-Repository Image Comparison and Annotation Tool
Mirador: A Cross-Repository Image Comparison and Annotation ToolIIIF_io
Introduction to the Presentation APIIntroduction to the Presentation API
Introduction to the Presentation APIIIIF_io

Último

h2 meet pdf test.pdfh2 meet pdf test.pdf
h2 meet pdf test.pdfJohnLee971654
Need for Speed: Removing speed bumps in API ProjectsNeed for Speed: Removing speed bumps in API Projects
Need for Speed: Removing speed bumps in API ProjectsŁukasz Chruściel
Understanding Wireguard, TLS and Workload IdentityUnderstanding Wireguard, TLS and Workload Identity
Understanding Wireguard, TLS and Workload IdentityChristian Posta
Future of SkillsFuture of Skills
Future of SkillsAlison B. Lowndes
Advancing Equity and Inclusion for Deaf Students in Higher EducationAdvancing Equity and Inclusion for Deaf Students in Higher Education
Advancing Equity and Inclusion for Deaf Students in Higher Education3Play Media
Improving Employee Experiences on Cisco RoomOS Devices, Webex, and Microsoft ...Improving Employee Experiences on Cisco RoomOS Devices, Webex, and Microsoft ...
Improving Employee Experiences on Cisco RoomOS Devices, Webex, and Microsoft ...ThousandEyes

The IIIF Image API

Notas del editor

  1. 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.
  2. 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.
  3. Without standards we can only have closed systems, servers clients that understand a particular, unique protocol.
  4. 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
  5. 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.
  6. 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.
  7. 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
  8. Actual image is 5204 x 7200; this is scaled to fit the slide
  9. We don't expect humans to construct this, but this gives you a nice, clean, reusable (cacheable) URI
  10. Previously select region rotated by 90 degrees, can also mirror
  11. You can't tell it's a png, but trust me….
  12. 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
  13. 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
  14. 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