Handle image annotations that have no IIIF service

[tomcrane]

A sequence in a manifest is a list of canvases, the images are annotations on the canvas. Provision of a "service" for an image is optional - the canvas might just link to a JPEG directly, no deep zooming.

http://iiif.io/api/presentation/2.0/#image-resources:
"If a IIIF Image API service is available for the image..." - (it might not be).

In this case the UV should just render the referenced image (the @id of the resource) as a regular image rather than an OSD canvas. This scenario still supports every other aspect of IIIF - annotations, search within etc - but without the deep zoom. UV would need to paint search results, and other annotations onto an "img tag" instead of OSD canvas.

This allows you to construct a "crick-Watson letters" style manifest from a mixture of IIIF endpoints and regular images at URIs and still have annotations on everything.

[tomcrane]

They may or may not have auth: IIIF/api#547

[tomcrane]

In the absence of a service the UV should construct a new single-image tileSource and pass that to OSD. e.g., given:

  "resource": {
    "@id": "http://example.org/iiif/book1/res/page1.jpg",
    "@type": "dctypes:Image",
    "format": "image/jpeg",
    "height":2000,
    "width":1500
  }

pass this to OSD as the tileSource

tileSources: {
        type: 'image',
        url:  'http://example.org/iiif/book1/res/page1.jpg',
        buildPyramid: false
    }

https://openseadragon.github.io/examples/tilesource-image/

I suspect that given the likely cross-origin nature of any image and the fact that this is not a IIIF tileSource, buildPyramid will have to be false always.

Unless there's some reliable and quick way of probing the CORS headers on the image. Suck it and see.

[tomcrane]

Download menu will need to handle no image service on the image resource.

[tomcrane]

NB this use case is IIIF fixture number 1: http://iiif.io/api/presentation/2.0/example/fixtures/1/manifest.json

[LeighBicknell]

Has this feature been implemented as yet?

[tomcrane]

Other issues to think about

• download menu can only offer the full size image download, no current view
• For thumbnails to work, you need Use explicit thumbnail resource when specified #102. However, I don't think that needs to be a dependency on this issue. Having the manifest work but with blank thumbs is better than not having the manifest work at all.

[tomcrane]

@FlickerBean - yes!