remote dzi

[ajwarnick]

is it possible to have a remore dzi instead of a local dzi and file directory.

currently we are using seadragon and it has a proxy and our tiles are being served by a different host.

this is the seadragon proxy config: Seadragon.Config.proxyUrl = '/collections/iipsrv?site=';

[iangilman]

Looks like that functionality doesn't exist in OpenSeadragon, but it would be easy to add back in; I'll take a look at it.

In the meantime, depending on how you have things set up, you could handle the situation in a few different ways: pass the dzi information directly into OpenSeadragon (rather than having it load it), or use jsonp (which avoids the need for a proxy). You can see some examples here: http://thatcher.github.com/openseadragon/examples/tilesource-dzi/

[dgutman]

What's the syntax to use jsonp with openseadeagon

Say I have my dzj images on imagesrv01 and I'm running my openseadragon from client01 On Jan 16, 2013 4:24 PM, "iangilman" notifications@github.com wrote:

Looks like that functionality doesn't exist in OpenSeadragon, but it would be easy to add back in; I'll take a look at it.

In the meantime, depending on how you have things set up, you could handle the situation in a few different ways: pass the dzi information directly into OpenSeadragon (rather than having it load it), or use jsonp (which avoids the need for a proxy).

— Reply to this email directly or view it on GitHubhttps://github.com/thatcher/openseadragon/issues/21#issuecomment-12340854.

[iangilman]

@dgutman check out the "JSONP Request for DZI JSON" section on http://thatcher.github.com/openseadragon/examples/tilesource-dzi/

[dgutman]

Ok I've seen that--- I still screw up the syntax though..

I almost exclusively use

viewer.openDZI('http://thesamemachine/foo.dzi.tif')

Can I still use the same function call but somehow "jsonpize" it.... I am not using traditional DZI files... I am instead using IIPSRV.fcgi which basically dynamically generates the DZI tiles on the fly--- I honestly think this is a much better solution than having hundreds of thousands of small tiles on my file system.... but because of that I can't readily change it

so I call

http://node15.cci.emory.edu/cgi-bin/iipsrv.fcgi?DeepZoom=/bigdata/PYRAMIDS/CDSA/GBM_Diagnostic/intgen.org_GBM.diagnostic_images.Level_1.3.2.0/TCGA-06-0137-01Z-00-DX8.a5703515-8d5f-4bfd-8f5a-a66581641e3b.svs.dzi.tif.dzi

and the response looks like:

<Image xmlns="http://schemas.microsoft.com/deepzoom/2008" TileSize="256" Overlap="0" Format="jpg">

But I may want to host openseadragon server on node16.. or my desktop, or wehever...

Is there a clean way to do this?

On Wed, Jan 16, 2013 at 6:03 PM, iangilman notifications@github.com wrote:

@dgutman https://github.com/dgutman check out the "JSONP Request for DZI JSON" section on http://thatcher.github.com/openseadragon/examples/tilesource-dzi/

— Reply to this email directly or view it on GitHubhttps://github.com/thatcher/openseadragon/issues/21#issuecomment-12345549.

David A Gutman, M.D. Ph.D. Assistant Professor of Biomedical Informatics Senior Research Scientist, Center for Comprehensive Informatics Emory University School of Medicine

[teaforthecat]

@dgutman we are also using iipsrv, and would like to switch to openseadragon So it seams like the requested feature would be: support iipsrv server by parsing dzi xml into json, or lets see if I understand the steps if using iipsrv, one must

• pass a url to a javascript file to initialize openseadragon with jsonp
• the javascript returned by the url would contain a function which makes a request to iipsrv to get the dzi xml then,
• parse that xml, then,
• return the json dzi for openseadragon. I am understanding this correctly?

Thanks

[dgutman]

yeah... that sounds about right

the http://zoom.it/ does something similarish.. i had manually edited one of the generated files and got it to work with a dzi pointing to my iip server instance...

On Thu, Jan 17, 2013 at 2:06 PM, Chris Thompson notifications@github.comwrote:

@dgutman https://github.com/dgutman we are also using iipsrv, and would like to switch to openseadragon So it seams like the requested feature would be: support iipsrv server by parsing dzi xml into json, or lets see if I understand the steps if using iipsrv, one must

• pass a url to a javascript file to initialize openseadragon with jsonp
• the javascript returned by the url would contain a function which makes a request to iipsrv to get the dzi xml then,
• parse that xml, then,
• return the json dzi for openseadragon. I am understanding this correctly?

Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/thatcher/openseadragon/issues/21#issuecomment-12383587.

David A Gutman, M.D. Ph.D. Assistant Professor of Biomedical Informatics Senior Research Scientist, Center for Comprehensive Informatics Emory University School of Medicine

[iangilman]

What may work best for you is to grab the DZI data yourself and pass it to OpenSeadragon. Something like:

var dziUrl = 'http://node15.cci.emory.edu/cgi-bin/iipsrv.fcgi?DeepZoom=/bigdata/PYRAMIDS/CDSA/GBM_Diagnostic/intgen.org_GBM.diagnostic_images.Level_1.3.2.0/TCGA-06-0137-01Z-00-DX8.a5703515-8d5f-4bfd-8f5a-a66581641e3b.svs.dzi.tif.dzi';

$.ajax({
  url: '/proxy?url=' + encodeUriComponent(dziUrl),
  success: function(data) {
    viewer.openDZI(data);
  }
});

[iangilman]

Hmm... I haven't actually tried that, but I'm not sure how it would know where to get the tiles from... so maybe you would need to parse the xml yourself and call viewer.openTileSource() with the data as an object, as per the "Inline Configuration for DZI" section of http://thatcher.github.com/openseadragon/examples/tilesource-dzi/

[dgutman]

Also openseadragon works extremely well with IIPSRV--- I am basically rewriting my entire site (http://cancer.digitalslidearchive.net/ ) which has like 20,000+ whole slide images in it and uses IIPSRV for the backend.

The original app is written in Flex/Flash and I'm almost done porting the entire thing over to use openseadragon instead--- only issue I've had is that my production server is on a different domain than my dev box so I was running into the cross-domain issues I mentioned above--- I found a work around on my DEV box by screwing around with Apache configuration to finally get it working, but ideally I'd like to be able to have other sites/users/whoever to be able to stream the images from my image repository to whatever viewer they may want ..

ALSO--- unrelated-- but could someone point me towards where in openseadragon the tag that is passed to the viewer with the actual small image tiles in it is located? I wanted to try and add an additional parameter in the tag so I can so some client side manipulation of the images--- I am a couple of lines of code away (I think) , at least in chrome, to be able to change contrast/brightness/etc on all the tiles I am rendering--- right now though I seem to be ajusting the entire openseadragon DIV, and what I really want is to only apply the filters to the actual image tiles and now the entire DIV... so I thought if I added class (or maybe id) to the img tag, I'd have a handle to do some manipulations..

[teaforthecat]

dgutman I assume you mean that you set the Allow from all hosts setting in apache. Is that right? Would you mind posting how you configure seadragon to use another domain please?

[dgutman]

Yeah sorry--- I realize it was a bit unclear... and this is what works on my Ubuntu system...

So the key is: " Header set Access-Control-Allow-Origin "" " I may change it to only allow cross-domain requests originating from a certain domain instead of having the "" in it.... I have to play around with the synax...

So this has to be on the server where openseadragon is running from, NOT where the iip images live.. In retrospect it's kind of obvious, but I originally thought I had to modify the image server's apache, not the one running the client...

Also a BIG warnings ... 1) This is probably the least secure way to do it, but this is a local dev box and it worked, so I was happy

So in /etc/apache2/sites-available

I edited the default --- if I had set up specific directories for specific apps, I would probably just insert the code there...

The fourth line is what I had inserted-- this basically tells my apache server that it should NOT block cross domain requests to other domains if the document requesting them lives in /var/www or its children...

It would be more secure to specify a separate virtual host for like /var/www/SLIDE_DEV/ or something, but I have multiple projects that all retrieve images from the same server, and am constantly adding/deleting projects...

<VirtualHost *:80> ServerAdmin webmaster@localhost

    Header set Access-Control-Allow-Origin "*"
    DocumentRoot /var/www
    <Directory />
            Options FollowSymLinks
            AllowOverride None
    </Directory>
    <Directory /var/www/>
            Options Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
            AllowOverride None
            Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
            Order allow,deny
            Allow from all
            Header set Access-Control-Allow-Origin *
    </Directory>

..... (My default file had additional code)

On Sun, Jan 20, 2013 at 9:31 PM, Chris Thompson notifications@github.comwrote:

dgutman I assume you mean that you set the Allow from all hosts setting in apache. Is that right? Would you mind posting how you configure seadragon to use another domain please?

— Reply to this email directly or view it on GitHubhttps://github.com/thatcher/openseadragon/issues/21#issuecomment-12482623.

David A Gutman, M.D. Ph.D. Assistant Professor of Biomedical Informatics Senior Research Scientist, Center for Comprehensive Informatics Emory University School of Medicine

[thatcher]

sorry for chiming in late, Ian (who is one of the original authors!) has been good enough to volunteer to help manage this project because my workload prevents me from keeping up regularly.

When you are trying to use dzi xml files from remote hosts the Access-Control-Allow-Origin header is one viable option if you are comfortable with it, though not all older browsers will support it.

Another option is called 'inline configuration'. Inline configuration is very useful when you are able to simply make a request for the dzi from the server-side, parse it, and provide the details of the dzi as part of the rendered html page.

Here is an example of how it can be rendered as an inline configuration ( taken from http://thatcher.github.com/openseadragon/examples/tilesource-dzi/ ):

OpenSeadragon({ ... tileSources: { Image: { xmlns: "http://schemas.microsoft.com/deepzoom/2008", Url: "/openseadragon/examples/images/highsmith/highsmith_files/", Format: "jpg", Overlap: "2", TileSize: "256", Size: { Height: "9221", Width: "7026" } } } ... });

You can see the inline configuration can be easily generated from the dzi xml and the key is adding the correct 'Url' key so that the client understands where the images are hosted from. The client cant tell the difference between static dzi tiles and those hosted by your IIPSRV sever application.

When you use this approach you dont have to care where the dzi resides because http requests on the server-side have no constraints as to where they can make http requests to. A proxied request from the client, as Ian pointed out, is a viable alternative; however, inline configuration is a much simpler solution in most cases and ensures you can render dzi xml hosted anywhere on the web.

I can provided additional clarification if you need it because I realize that many web developers still are not familiar with server-side http access to resources as a programming pattern.

Thatcher

[iangilman]

@dgutman, regarding processing the individual tiles, it sounds like you're asking for where the tiles live in the DOM? In most browsers the tiles aren't attached to the DOM at all, but simply drawn into a single canvas element that's attached to the DOM. I suppose one approach would be to process the canvas. Another approach would be to hook into OpenSeadragon where the tiles are fetched and process them as they arrive. Which is more efficient depends on how frequently you want to change the processing. I'd say I'm leaning towards the latter approach as a general solution, as I don't think we use the single canvas for every browser. If this is of interest, you can start a fresh issue for it.

[dgutman]

thanks--- I've been experimenting with using SVG filters to recolor/brighten things.. and it works well

I was able to recolor everything in the actual canvas-- I did find a DIV for each individual image as it's rendered onto the canvas (or overlaid).. the DIV itself just didn't have a classname='something' and I wasn't sure where in the openseadragon.js base where I could potentailly add a classname tag to each of the tiles....

I'll work on posting a simple demo in the next couple of days to show you what I mean..

On Thu, Jan 24, 2013 at 1:26 PM, iangilman notifications@github.com wrote:

@dgutman https://github.com/dgutman, regarding processing the individual tiles, it sounds like you're asking for where the tiles live in the DOM? In most browsers the tiles aren't attached to the DOM at all, but simply drawn into a single canvas element that's attached to the DOM. I suppose one approach would be to process the canvas. Another approach would be to hook into OpenSeadragon where the tiles are fetched and process them as they arrive. Which is more efficient depends on how frequently you want to change the processing. I'd say I'm leaning towards the latter approach as a general solution, as I don't think we use the single canvas for every browser. If this is of interest, you can start a fresh issue for it.

— Reply to this email directly or view it on GitHubhttps://github.com/thatcher/openseadragon/issues/21#issuecomment-12665479.

David A Gutman, M.D. Ph.D. Assistant Professor of Biomedical Informatics Senior Research Scientist, Center for Comprehensive Informatics Emory University School of Medicine

[teaforthecat]

Thanks @thatcher that is an excellent explanation. It sounds like the recommended approach is to run a proxy on the same domain that the page is on.
The project I'm working on is pretty much all zoom all the time, so I am concerned about performance and scalability of a proxy.^1

Let me try to rephrase how one would go about using an alternate domain:

• setup Access-Control-Allow-Origin on the alternate domain.
• prepare the meta data about the image: Format, TileSize, Height, Width (from dzi or stored in db perhaps)
• call OpenSeadragon with the inline configuration (tileSources) mentioned above using the alternate domain in the url parameter e.g.: Url: 'http://alternate-domain.com/iipsrv/some-image.dzi'

Thanks!

^1: If you disagree about the downside of a proxy, please let me know. Basically we are concerned with our app server taking on a lot of requests both ways. I think one performant way to handle it would be to use nginx upstream to point at the image server, with some advanced cacheing service like redis, or memcached.

[iangilman]

@dgutman: Sounds great, thanks!

@teaforthecat: Using a proxy is a pretty common technique, and it should scale reasonably well. Remember you only need to proxy one request per DZI image you show; none of the tiles are proxied, for instance. If the proxy calls start to add up, you can switch to using Access-Control-Allow-Origin instead (you wouldn't use both techniques at the same time, as they're redundant to each other). Note that with Access-Control-Allow-Origin, you can specify a whitelist of specific domains you allow access from.

Another approach is to store the image tiles on the remote server but keep the DZI data files (each of which are very small) on the same server as your website; in this way you avoid the need for a proxy entirely. You'd just load the appropriate data file and use the inline configuration.

[thatcher]

I'm going to go ahead and close this for book keeping while we move the repo. thanks for the great discussion

[wilkinson]

I would like to reopen this issue, as it was never truly solved -- alternatives were proposed, and this issue was closed for bookkeeping purposes. It would be great to have a client-side-only way to resolve remote DZI files that reference remote image tiles. Is this already possible?

[iangilman]

It was closed because there's no way for OpenSeadragon to provide a client-side only way to access XML DZI files from remote servers. Options include:

• Setting up CORS on the remote server.
• Putting a proxy on the local server to talk to the remote server.
• Serve the DZI file information from the remote server as a JavaScript file (i.e. JSONp).
• Store the DZI file information on the local server, and keep the image tiles on the remote server.

All of these work with the existing OpenSeadragon, and all of them require changes to your server(s).

On the other hand, if there is a way to fix it with OpenSeadragon alone that I'm not aware of, I'd love to hear about it!

[wilkinson]

According to the Zoom.it documentation, you can retrieve nearly all of the necessary parameters for use with OpenSeadragon by making a JSONP call (shown here with jQuery):

var id = '11mb';

$.ajax({
    dataType: 'jsonp',
    success: function (response) {
     // This function is the callback for a successful AJAX request.
        console.log(JSON.stringify(response.content, undefined, 4));
        return;
    },
    url: 'http://api.zoom.it/v1/content/' + id
});

I see the following output:

{
    "id": "11mb",
    "url": "http://example.com/",
    "ready": true,
    "failed": false,
    "progress": 1,
    "shareUrl": "http://zoom.it/11mb",
    "embedHtml": "<script src=\"http://zoom.it/11mb.js?width=auto&height=400px\"></script>",
    "dzi": {
        "url": "http://cache.zoom.it/content/11mb.dzi",
        "width": 1024,
        "height": 600,
        "tileSize": 254,
        "tileOverlap": 1,
        "tileFormat": "png"
    }
}

Note especially that the dzi property contains all of the properties of the Deep Zoom Image itself, except for the schema and the server format. If someone knows either how to assume these things safely or else deduce them cleverly, then we would have all we need. If there's no way to do it, though, then YQL could be useful -- try a corresponding example live in the YQL Console. I'm happy to write the code, but I don't know how the project leaders feel about using external web services. Let me know :-)

[iangilman]

I believe the schema will always be http://schemas.microsoft.com/deepzoom/2008. The format is listed above as tileFormat. All you need to do is put the appropriate bits into a tileSource param, as shown in the "inline configuration" section of:

http://openseadragon.github.io/examples/tilesource-dzi/

Let me know if you have any trouble with that.

Adding support for YQL could be handy, but I wouldn't want OpenSeadragon core to take a dependency on the web service... it would make a great plugin, though. See:

https://github.com/openseadragon/openseadragon/wiki/Making-OpenSeadragon-Plugins

[ghost]

I have seen many different references to the DZI XML Schema at, http://schemas.microsoft.com/deepzoom/2008

Is that Schema still there? How can you determine that it is still there? Is it required?

[iangilman]

Even though the Schema is no longer at that location, that URL serves as a marker to identify a properly formatted DZI. The format itself hasn't changed in the intervening years. For more info on the format, see:

http://msdn.microsoft.com/en-us/library/cc645077%28v=vs.95%29.aspx http://msdn.microsoft.com/en-us/library/cc645022%28v=vs.95%29.aspx

[ghost]

Right, in between asking my question and your response I found some more information. Thank you very much for the reference links.

My remaining question is whether or not the schema is required at all? I suspect not, as it's absence does not readily appear to unduly interfere with the operation of openseadragon.js.

If it is required, then I suppose I could server up a local copy?

[iangilman]

Well, there are two questions here: is it required that that URL be listed in the file you provide to the viewer, and is it required that there be something on the server that that URL points to.

For the first question, it looks like it is required:

https://github.com/openseadragon/openseadragon/blob/master/src/dzitilesource.js#L106-L116

For the second question, it's definitely not necessary. At this point that URL is just a marker to indicate the type of format; there's no need for there to be something at that location.

Does that make sense?

[ghost]

Many thanks.