IIIF integration

[sharonmleon]

We should discuss integrating IIIF support in Omeka S. There seems to be a good number of platforms and tools that are looking to incorporate it in some way. The possibilities include (from Mark Matienzo):

1. Initial support for the IIIF Image API on the server side, which would mean that images could be easily reused in different contexts in or outside of Omeka S
2. Initial support for the IIIF Presentation API on the server side (e.g. publishing manifests), which means that Omeka S resources could be more easily brought into other viewing interfaces
3. Consuming IIIF manifests as a source of data for external Omeka objects
4. Viewers to bring in local and remote IIIF images
5. Incorporation of a scholarly viewing/annotation environment

[patrickmj]

Interest does seem strong. In response to my query on the code4lib listserv for Fedora 4 endpoints to test against, it came up in a PS https://listserv.nd.edu/cgi-bin/wa?A2=ind1507&L=CODE4LIB&F=&S=&P=58689

[zerocrates]

One thing to think about in the more immediate term for leaving the door open to the more limited "levels" of support: you have to be able to respond to any request with a JPEG image. For us, that most easily means making another derivative/"thumbnail" type that's just a JPEG conversion at full size.

Otherwise, I think the only alternatives that comply with the standard are making only things that were JPEG to begin with available, or only making the thumbnail sizes available, which would seem to defeat the purpose.

[zerocrates]

I'm referring to the "Level 0" features from this document: http://iiif.io/api/image/2.0/compliance.html

I neglected to mention an additional option: supporting the standard more fully would mean creating derived images on-the-fly in response to the request... it's possible to set things up that way, but obviously more complicated than just exposing the sizes we already have available.

[patrickmj]

Thanks. I remember some of the conversations that brought up these issues. Clearly a lot to deal with, if we move toward that support.

[zerocrates]

It's also worth noting that the PS you posted really refers to Sharon's point 3: consuming IIIF resources.

We could look into doing that as a Media type. Chucking a IIIF URL into an OpenSeadragon viewer could be a pretty low barrier to clear for at least supporting the Image API. I'm not as sure what's required on the presentation API side.

[patrickmj]

Oooh! Good point. That direction and emphasis fits well with the 'Omeka-as-public-presentation-layer' that we've heard elsewhere (Fedora, DSpace, ArtStore), and is what we're all about. For a first or soon-after-the-first release, a Media type for that and OpenSeadragon might be just the ticket. 🎫

[zerocrates]

If we're really thinking about doing this, we could carve out the "OpenSeadragon-based media type" part into its own issue.

[klokan]

There is the open-source IIIF plugin for Omeka now available at: http://omeka.org/add-ons/plugins/iiif/ with source code at: https://github.com/klokantech/omeka-plugin-IIIF

It does:
2) support for the IIIF Presentation API on the server side (e.g. publishing manifests), which means that Omeka resources could be more easily brought into other viewing interfaces DONE
3) Consuming IIIF Image API info.json as a source of data for external Omeka objects. Presentation API manifest which would bring into Omeka not only the image, but also metadata - could be added easily - pull request for klokantech/omeka-plugin-IIIF#3 is welcome ;-) partly DONE
4) Viewers to bring in local and remote IIIF images DONE

In other words the plugin serves IIIF Presentation API manifests derived from metadata in Omeka, and is able to consume and natively reuse for thumbnails and preview images from a remote IIIF Image API server located anywhere in the internet. It comes with zoomable viewer powered by OpenSeaDragon.

The plugin does not generate local image tiles to be compliant to "Level 0" of Image API, but this could be added if required. Right now it could, if configured, push instead the in the administration uploaded images to a remote image service - to get a true IIIF with "Level 2+" support.

This is open-source project on GitHub, which can be further improved by anybody - to add functionality which others needs. We would be very glad if others use the add-on.

[patrickmj]

@klokan
Thanks....we've been in touch and watching the work on this.

Important to note, though, that this is the repo for a completely new version of Omeka, Omeka S, which is very different in many ways from the Omeka 2 series that your IIIF plugin works on. Omeka S is just in alpha releases, and Omeka 2 and Omeka S will continue to exist in parallel for the foreseeable future.

[saracarl]

Please see also my comment in issue #870 for a small-yet-important piece of functionality we need from omeka S in order to continue the IIIF support @Daniel-KM has been providing via the IIIF modules.
#870 (comment)

[jimsafley]

We're currently working towards a simple IIIF ecosystem that includes a IIIF Presentation module, a core IIIF viewer (Mirador), and a IIIF Presentation media type. We've decided to postpone implementation of IIIF Image and annotations until we can conceive a simple way to do so.