Skip to content

Instantly share code, notes, and snippets.

@jkeck

jkeck/spotlight-iiif-proposal.md

Last active January 13, 2017 19:36
Show Gist options
  • Save jkeck/642d31eedf005a6431b9e69e7e384301 to your computer and use it in GitHub Desktop.
Save jkeck/642d31eedf005a6431b9e69e7e384301 to your computer and use it in GitHub Desktop.
Download ZIP
A brief proposal (and some other notes) on implementing IIIF cropping in Spotlight
Raw
spotlight-iiif-proposal.md

In order to support IIIF cropping of multi-image objects (which is currently supported in a non-IIIF way), we'll need to use IIIF manifests. Storing a list of info.json URLs will not be sufficient since the URL typically contains the file name of the item (at least in our case). This is potentially volatile in the case of remediations that changes file names. A IIIF manifest has references to the images contained within an object (as well as unique identifiers that we can use that will not change during remediation). This will require some changes that are outlined below.

Persisted Data

Currently we persist the URL to the masthead/thumbnail image itself (the act of submitting a crop selection for a masthead/thumbnail causes a fetch of the full image and does the image cropping server side). We still want to persist a URL to an image so we don't have to hit the IIIF service to get the cropped image URL, however we will need to persist some other data from the IIIF manifest to ensure that we're referencing the same image (regardless of images being renamed, remediated, etc) or at least can re-construct that image URL given the stored identifiers. Right now, the url to the actual image is persisted through some database relationships that CarrierWave sets up (which we can probably simplify with this work).

For masthead/thumbnails

  • Need to store manifest URI
  • Need to store canvas URI
  • Need to store annotation/image ID
    • Note: An annotation/image does not require an ID and it is not required to be an HTTP URI. We will need some logic of what to do if there is no ID (most likely choose the first).
  • Need to store crop box coordinates
    • Question: Would the full image URL suffice here? Is it worth just storing the coordinates anyway so we don't have to attempt to parse them out of the image URL in the case of needing to re-construct the image URL in the case of a rename?

For solr documents

  • Need to store manifest URI
  • Question: What data should we store to be able to build static images around the site (e.g. thumbs)? Full IIIF urls? A base URL that we can construct a URL from using IIIF params?

Note on multiple annotation/images within a canvas

At first it seemed like we would only need to persist URIs to the canvas layer, however it is possible to have multiple images within a single canvas. A use case for this is multispectral imaging where each image within a canvas is the same image just different spectrums. We don't have these currently and supporting these are most likely out of scope (we'll probably just go with the first, but this is certainly up for discussion).

File Upload

A user has the ability to upload and crop an image directly from their desktop to create a masthead or thumbnail (also about page contact avatar FWIW).

  • Current implementation in the iiif branch is to upload image via ajax and return a IIIF tilesource (i.e. info.json) in the response.
  • Question: Should we generate and return a IIIF manifest for ajax-uploaded files instead of a info.json for consistency?

Current Issues

  • Spotlight's javascript to implement the iiif-cropper currently only works with file uploads (i.e. not with auto-complete of exhibit items)
  • IIIF-Cropper does not seem to work well with multiple croppers on the same page (could be spotlight's implementation?)
  • Scrolling zoom does not seems to not work in the current implementation
    • Not sure if this is related to the chrome fix or not.

Tasks

  • Generate manifests for uploaded documents (Issue)
  • Generate manifests for ajax-upladed files?
    • This may be unnecessary. The code to initialize a cropper will always be at the tilesource/info.json level and will need to be instantiated differently for a file-upload vs. autocomplete anyhow.
  • Add configuration to identify which solr field stores the manifest URL
  • Use IIIF resource IDs to construct a unique canvas URI @id (in PURL).
    • We have some objects that will require remediation since they do not have unique resource IDs
  • If we need to store crop-box coordinates separately, we will need to use a cropper that can give us that data
  • Potentially switch to leaflet-iiif-cropper
    • If it addresses the bugs outlined above in Current Issues
  • Update contact avatar, masthead, and thumbnail models to store relevant data outlined above
  • Update cropper implementing code to parse the tilesource from the relevant IIIF manifest
  • Support multi-volume (e.g. viewingHint multi-part).
  • Test migration script
  • ???

Relevant links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment