tomcrane

The current 2-up implementation was developed from the British Library's materials - but in those cases the facing pages were already cropped and framed to give a consistent viewing experience, so the problem wasn't seen. I suspect it would have been before long.

What's happening currently The UV code is postitioning the recto tile source on the canvas so that it aligns with the top of the verso image, and adds a small gutter between them (the size of this gutter is configurable, the current value is the result of user testing at the BL). What happens next is down to the OpenSeadragon library [0] that we use to render the deep zoom images. Currently this is what is scaling the images to be the same width. We need to prevent it doing that.

Quick fix - The only metadata the UV has to go on is that the pair of images are the verso of one page and recto of the following page - and even that information is inferred from the sequence rather than explicit in the metadata (but see https://digirati.atlassian.net/bro

tomcrane

Regular clickthrough

• http://wellcomelibrary.org/item/b19999860

interstitial clickthrough

• http://wellcomelibrary.org/item/b19900004

full CAS

• http://wellcomelibrary.org/item/b20000017

Restricted

tomcrane

• Does OSD handle an info.json with szes only (no tiling?)
• If so use shimmy to generate info.json from flickr sizes
• requires proxy to rewrite iiif -> flickr images

https://github.com/mejackreed/shimmy

Make shimmy -> DLCS integration

---

tomcrane

General

sequence -> canvases

OK for video. A canvas with a time dimension. "duration"... (dc?)

Is "canvas" general enough for audio, born digital, 3D?

tomcrane

Issues

• [IIIF/api#526 auth from Presentation #526)
• [IIIF/api#547 auth for image resources rather than Image API services #547)

Field of thumbnails

Thumbnails with overlays

Manifests

tomcrane

getThumbnail(..)

Motivation

Generally, to encapsulate the logic for getting the best possible thumbnail for a resource, given the user's current known auth status for those resources. Anyone using manifesto or some other library that implements this can just call getThumbnail(..) and not worry about the details. Most of the time auth is not an issue, but if it is, they still don't need to worry about the details, getThumbnail(..) will figure it out and return the best thumbnail the user can currently see (which may be no thumbnail). Crucially, getThumbnail() assumes that the best thumbnail is the FASTEST one, within reason; that viewers favour speed over a precise size because they can scale an image in the browser.

Specifically, to help viewers generate a "field" of thumbnails as quickly as possible. Mirador, UV and other viewers all show large numbers of thumbnails at once. This can give a poor user experience, especially if viewers ask for arbitrary image sizes which

tomcrane

IE8 and IE9 have the HttpXmlRequest object, but unlike the implementation in IE10+ and current versions of Safari, Chrome and Firefox it does not support CORS, so will not allow you to attempt any kind of cross domain request.

In IE8 and IE9, Microsoft separated out cross domain activity into the XDomainRequest interface:

https://developer.mozilla.org/en-US/docs/Web/API/XDomainRequest

This sits alongside XmlHttpRequest in IE8 and IE9 (and was dropped in IE10 when XHR became fully-CORS), and you use it when you want to go cross domain. This works fine for many Ajax scenarios, and you can shim it into jQuery with this library, which hides the distinction between the two interfaces when you do CORS from jQuery:

https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest

tomcrane

Protecting binaries - extending the auth flow beyond JSON-LD resources

This applies to image resources (as opposed to pixels returned from an IIIF image service). It also applies to audio, video, PDFs and any other resource for direct consumption by the end user that isn't a service with an info.json descriptor.

Problem:

The expected client implementation of http://iiif.io/api/auth/0.9/#workflow-from-the-client-perspective uses XHR to request the info.json. The response body is always the same regardless of the user's access (we don't protect the information carried in the info.json) but the HTTP status code differs. A client can detect the presence of a IIIF auth service in the info.json, allow the user to log in at the URI provided, obtain an access token from the token service provided, and then crucially present that access token to the info.json service in a second request (using an Authorization HTTP header) to determine whether

tomcrane

var decoded = Convert.FromBase64String(samlRequest);
var zlibPadding = new [] { decoded[0], decoded[1] };
var deflated = CompressionUtils.Deflate(decoded.Skip(2).ToArray());
Log.Info("decoded SAMLRequest:");
Log.Info(deflated);
var sessionIndex = CasAuthentication.ExtractSingleSignOutTicketFromSamlResponse(deflated);
Log.Info("Extracted sessionIndex: " + sessionIndex);

LibraryAuthentication.SignOut();

tomcrane

We want to move the Wellcome Library away from the Wellcome Player and onto the IIIF 2.0 Universal Viewer (UV).

This allows us to move all the Wellcome Library's image API endpoints to the protoype DLCS (Digital Library Cloud Services) that we have started building.

We have a problem. We have video, audio and born-digital content, besides image sequence content. We don't want to maintain the Player and the UV together. This non-image content is a tiny fraction of the total, but an important one.

Other institutions share this problem, and everyone agrees that IIIF will need to extend to handle non-image-sequence resources - "IxIF". We want to inherit all that we can from IIIF - the JSON-LD, the Open Annotation model, the manifest wrapper and general approach to metadata ("presentation not semantics"). Shared Canvas may be appropriate for some media but not others.

• Images are canvas-based media - they occupy a region of a plane. Annotations are on regions of the plane.
• Audio is a time-based medium - i