Support for IIIF Image API standard?

[ksclarke]

This is more of a feature request than a bug/issue. How about supporting the emerging IIIF API?

http://www-sul.stanford.edu/iiif/image-api/

Client-side could make requests back to the image server using this RESTful pattern.

[thatcher]

I suck kevin, not because Im not working but because I'm not communicating. Ian Gilman is one of the original authors of OpenSeadragon, and he's taking over the frontman position, communication, ticket management.

Although I havent committed this work, I have played with IIIF in OpenSeadragon and preliminary work for supporting this spec in my daily work.

One thing that would help me get this done fast is a public server with some examples of the server spec in use. Have anything I can develop against without running a server myself?

Thanks
Thatcher

[jpstroop]

Thatcher,
I may be able to help. Here[1] is my dev server for Loris[2], which (intends to be) an implementation of IIIF level 2, e.g.

http://lorisimg.princeton.edu/loris/pudl0001/4609321/s42/00000004/full/full/0/color.jpg
http://lorisimg.princeton.edu/loris/pudl0001/4609321/s42/00000004/info.xml
http://lorisimg.princeton.edu/loris/pudl0001/4609321/s42/00000004/info.json

As I said, it's my dev server, and so I can't guarantee 100% perfection, but all of the tests are passing at the moment and all of the features should be there--I'm really just optimizing at this point. I'd be happy to keep you in the loop if something were to change drastically--I'm not working on the project at all at the moment, so it should be stable for at least the next few weeks, and if I move the sever the domain won't likely change. If you want some more image identifiers (i.e. "pudl0001/4609321/s42/00000004" in the URIs above) message me and privately and I'll be happy to oblige.

I can also tell you (forgive me if I'm stating the obvious) that the major difference between IIIF and most other request syntaxes is that the region parameters stay the same, regardless of the ultimate size of the image, so the result of e.g.:

http://lorisimg.princeton.edu/loris//pudl0001/4609321/s42/00000004/0,0,256,256/pct:50/0/color.jpg

is not 256 pixels square as you might expect, but 128. A while ago I worked out how to turn a DZI request into an IIIF request, thinking I'd build that into Loris. I've plunked that into a Gist[3], in case it's useful to you (in Python, not Javascript, unfortunately). I'm no mathematician, but it seems to work....

Best,
-Jon

(PS: sorry for the wacky formatting...last time I reply via email!)

1. http://lorisimg.princeton.edu/loris
2. https://github.com/pulibrary/loris
3. https://gist.github.com/4624253

[ksclarke]

Glad to see you saw this Jon. I was going to suggest Loris. I would have installed and run it for this purpose, but better to go right to the source. :-)

[thatcher]

Thanks, this is a huge help!

Sent from my iPhone
Christopher Thatcher
202-340-9685
thatcher.christopher@gmail.com

On Jan 24, 2013, at 11:28 AM, Jon Stroop notifications@github.com wrote:

Thatcher,
I may be able to help. Here[1] is my dev server for Loris[2], which
(intends to be) an implementation of IIIF level 2, e.g.:http://lorisimg.princeton.edu/loris/pudl0001/4609321/s42/00000004/full/full/0/color.jpghttp://lorisimg.princeton.edu/loris/pudl0001/4609321/s42/00000004/info.xmlhttp://lorisimg.princeton.edu/loris/pudl0001/4609321/s42/00000004/info.json
As I said, it's my dev server, and so I can't guarantee 100%
perfection, but all of the tests are passing at the moment and all
of the features should be there--I'm really just optimizing at this
point. I'd be happy to keep you in the loop if something were to
change drastically--I'm not working on the project at all at the
moment, so it should be stable for at least the next few weeks, and
if I move the sever the domain won't likely change. If you want some
more image identifiers (i.e. "pudl0001/4609321/s42/00000004" in the
URIs above) message me and privately and I'll be happy to oblige.
I can also tell you (forgive me if I'm stating the obvious) that the
major difference between IIIF and most other request syntaxes is
that the region parameters stay the same, regardless of the ultimate
size of the image, so the result of e.g.:http://lorisimg.princeton.edu/loris//pudl0001/4609321/s42/00000004/0,0,256,256/pct:50/0/color.jpg
is not 256 pixels square as you might expect, but 128. A while ago I
worked out how to turn a DZI request into an IIIF request, thinking
I'd build that into Loris. I've plunked that into a Gist[3], in case
it's useful to you (in Python, not Javascript, unfortunately). I'm
no mathematician, but it seems to work....
Best,
-Jon
1.
http://lorisimg.princeton.edu/loris
2.
https://github.com/pulibrary/loris
3.

https://gist.github.com/4624253

Jon Stroop
Digital Initiatives Programmer/Analyst
Princeton University Library
jstroop@princeton.edu

http://pudl.princeton.edu
http://findingaids.princeton.edu
http://www.cpanda.org

On 01/24/2013 12:00 AM, Chris Thatcher
wrote:

I suck kevin, not because Im not working but because I'm not
communicating. Ian Gilman is one of the original authors of
OpenSeadragon, and he's taking over the frontman position,
communication, ticket management.
Although I havent committed this work, I have played with IIIF
in OpenSeadragon and preliminary work for supporting this spec
in my daily work.
One thing that would help me get this done fast is a public
server with some examples of the server spec in use. Have
anything I can develop against without running a server myself?
Thanks
Thatcher

—
Reply to this email directly or view
it on GitHub.
—
Reply to this email directly or view it on GitHub.

[thatcher]

This resource is a big help, thanks. I'm hoping for a basic iiif client available within a couple weeks.

Thatcher

[jpstroop]

Sorry, I think I sent a draft message before it was finished. Was going to
say you should drop me a line when/if you'd like me to try your code on my
server.

On Feb 1, 2013 11:20 PM, "Chris Thatcher" notifications@github.com wrote:

This resource is a big help, thanks. I'm hoping for a basic iiif client
available within a couple weeks.

Thatcher

—
Reply to this email directly or view it on GitHub.

[thatcher]

Hi Jon and Kevin, thanks for the links! I was able to add basic support for IIIF thanks to the gist you provided, nice work. One thing IIIF doesnt address unfortunately is cross origin resource sharing using response headers or jsonp so even though I've added support for xml and json info usage I havent been able to test it. I did test inline configuration and have a sample page up here ( I didnt put a link on the page yet to it because I wanted to make sure it was ok to use your tile server for the example ). Could you check it out for me and tell me what you think?

http://thatcher.github.com/openseadragon/examples/tilesource-iiif/

Let me know if its ok to add a link to this page as a supported tile source, if we need to point to a different service we can work that out. It would be nice to link to the source page in the pudl for the object but I cant find it again, doh!

[jpstroop]

Wow, that looks awesome! I'm not articulate enough in the Javascript / JSON realm to give feedback to the IIIF folks about JSONP or how to get around cross site scripting, but I'm sure they would appreciate anything you have to say or advice you have to offer. They're really active at the moment.

I'm glad the Gist was useful...I wasn't sure!

Go ahead and use the example. It'll probably break at some point, but if/when this winds up on a production server I'll be sure to update you if there's a URL change.

PS: I'm going to move your code onto that server and (hopefully) make a quick viewer that uses openseadragon in the same domain. That should work, right?

[ksclarke]

Wow, that does look awesome! Nice work, guys.

Kevin

On Fri, Feb 8, 2013 at 10:35 AM, Jon Stroop notifications@github.comwrote:

Wow, that looks awesome! I'm not articulate enough in the Javascript /
JSON realm to give feedback to the IIIF folks about JSONP or how to get
around cross site scripting, but I'm sure they would appreciate anything
you have to say or advice you have to offer. They're really active at the
moment.

I'm glad the Gist was useful...I wasn't sure!

Go ahead and use the example. It'll probably break at some point, but
if/when this winds up on a production server I'll be sure to update you if
there's a URL change.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-13295518.

[thatcher]

the info.json and info.xml support is a little iffy until I test it, I'll set up a quick proxy server to hit and make sure it works. I'll ping you later this evening to let you know its tested and ready for you.

I'm going to join the iiif mailing list and make the suggestion to include optional support for JSONP and CORS so the protocols are at least described in the spec.

[jpstroop]

OK, sounds like a plan. I noticed that you have an extra property in
there ("tilesUrl":). Is that something you're going to recommend be
worked in? Or is it (somehow) your way of getting around the
cross-domain issue?

On 02/08/2013 01:18 PM, Chris Thatcher wrote:

the info.json and info.xml support is a little iffy until I test it,
I'll set up a quick proxy server to hit and make sure it works. I'll
ping you later this evening to let you know its tested and ready for you.

I'm going to join the iiif mailing list and make the suggestion to
include optional support for JSONP and CORS so the protocols are at
least described in the spec.

—
Reply to this email directly or view it on GitHub
#20 (comment)..

[thatcher]

yeah tilesUrl is mostly an internal property that I created, not the best name in retrospect, that refers to the image services application base url. for iiif, its everything before the image identifier.

its not a property that needs to be provided by the info.xml or info.json since the host can be inferred from the url. i guess it would be possible to use info.json or info.xml to point to a host that serves the image tiles from a different host that served the dzi, but its not part of the spec so it just happens to work that way because I needed it for inline configuration of the iiif tile source.

The inline configuration allows the application rendering the page to do the http request for info.json or info.xml and provide the details of the image and openseadragon script configuration as part of the page rendering, which in turns avoids the ajax call to the service on the client.

It's six one way, and half a dozen the other but does provide an important option for serverside rendering of all tile source details (this works the same for dzi, lip, and iiif but not osm, nor tms). It makes cross origin resource sharing very simple for the client ;)

Thatcher

[thatcher]

oops above...

... guess it would be possible to use info.json or info.xml to point to a host that serves the image tiles from a different host that served the -->dzi<--, ...

should be

guess it would be possible to use info.json or info.xml to point to a host that serves the image tiles from a different host that served the -->tiles<--,

and a note on osm and tms. they could provide all the details i just don't know of an official serialization of them.

[thatcher]

Im closing this now though I understand there are more features to support from iiif. lets track them in new tickets when the new repo and org are ready.

http://thatcher.github.com/openseadragon/examples/tilesource-iiif/