search

thatcher / openseadragon

This project has moved to its new github organization at github.com/openseadragon, please join us!
http://openseadragon,github.com/
37 stars 14 forks source link

Support for IIIF Image API standard? #20

Closed ksclarke closed 11 years ago

ksclarke commented 12 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

Thatcher

jpstroop commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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/thatcher/openseadragon/issues/20#issuecomment-13295518.

thatcher commented 11 years ago

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 commented 11 years ago

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 https://github.com/thatcher/openseadragon/issues/20#issuecomment-13303640..

thatcher commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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/