namrehs / OpenSeadragon.Gigapan

Display Gigapan tiles with OpenSeadragon
1 stars 0 forks source link

Works, but only intermittently #2

Open bdrichards opened 8 years ago

bdrichards commented 8 years ago

Thanks so much for the quick solution! However, when I substitute my Gigapan image ID (and width and height) , everything displays only intermittently. First time works like a charms, as expected. But clear the cache and hard reload (in Chrome) and only black screen displays. Tried in IE (ver 11) and nothing shows first time. Closed all browser windows and then attempted in IE and displays fine. While IE window is open, I attempted to view again in Chrome, but only get black screen and the following console errors (is it possible there is some kind of "lock" placed on image tiles on the Gigapan side?):

gp-osd-capture

namrehs commented 8 years ago

Woah. That is so strange. I see that same behavior just by trying to load the image in the browser via: http://tile155.gigapan.com/gigapans0/89093/tiles/r.jpg Like you describe, first time it loads, then it throws a 404. A while later it works again. Seems to be intermittent, though. Sometimes it reloads just fine and other times you get a 404. Yeah, must be some issue with the Gigapan site. Maybe temporary? Maybe they're doing maintenance or experiencing some server issues? Hopefully that's it and it'll start working reliably soon. If not, and if you can figure out a workaround, that would be great. Note that you can always use the plugin on a local version (GigaPan Stitch output files) by using the appropriate path to the local files instead of a url. I'll leave this issue open. If you figure anything out, please add a comment. Thanks!

bdrichards commented 8 years ago

Strange, yes! Here is more observation (at least something that seems consistent): Let's say it finally opens find in Chrome (leave this browse window open).... Open IE11, and get 404 error (leave this browser window open.... Close Chrome window, go refresh IE window and bingo!, opens fine in IE11 (if it doesn't, closing IE window and immediately re-opening works)!!!

Even if first attempt in Chrome fails in above scenario, the final try in IE11 seems to work (at least the five times I have tried).

More testing.......

bdrichards commented 8 years ago

Several observations and a SOLUTION? Some observations about the "behavior" of accessing tiles directly on gigapan.com:

  1. Severity seems to be client internet setup dependent -
    • bad on my campus workstation;
    • worse on my home Verizon Fusion cantenna;
    • better on my standalone wifi mobile hotspot
      1. Usually IE was behaving better than Chrome

HOWEVER, I uncovered the following format to use for the URL and I seem to have ZERO issues regarding loading of tiles (change the "tile555.gigapan.com" to "share.gigapan.org"): tilesUrl: 'http://share.gigapan.org/gigapans0/89093/tiles/'

I also uncovered python code for a utility to download from the gigapan site ..... but that's another day

namrehs commented 8 years ago

Thanks for continuing to troubleshoot this issue! Your example works for me, but unfortunately, that change doesn't work with my example. This does not work: tilesUrl: 'http://share.gigapan.org/gigapans0/155637/tiles/' but this does: tilesUrl: 'http://tile155.gigapan.com/gigapans0/155637/tiles/' There must be some inconsistency on the gigapan site and urls may need to be chosen on a case-by-case basis for use with this plugin. Unless you have a more elegant solution, what I might do is just update the example code to include your example URL as a comment to make it obvious to others who experience this same problem. What do you think?

bdrichards commented 8 years ago

After some testing, there may be a somewhat elegant method to at least provide in the example explanation: As to which"method" (using http://share.gigpan...... or tile155.gigapan.....), there seems to be some correlation with the date that the gigapan was uploaded. Although I need to be more exhaustive, I discovered the following: This image (dated Nov 2011) works with the "share" version: 91566-share while the following does not work well (hardly at all in Chrome, a little better in IE11): 91566-tile155

HOWEVER, this image (dated Dec 2012) seems to work just the reverse (best in the tile155 subdomain, worst in the share): 120105-share vs. 120105-tile155

Give these a check, and, as I contend, there may also be some correlation with the client-side internet configuration .... Bill

namrehs commented 8 years ago

Thanks for continuing to explore this. It demonstrates the perils of relying on 3rd party websites for content.

To be honest, I wrote this plugin for use on local files, not necessarily the GigaPan site (since I have no control over what happens to the content on that site in the future), but since the particular GigaPan URL I used worked, I included that URL to make an easy example without having to add image files to the GitHub project.

I'm glad you're figuring out how to make it work on the GigaPan site and hope you can come up with an elegant solution for that.

As this plugin is intended specifically to allow openseadragon to traverse the GigaPan hierarchy of tiles, the details of where those tiles reside and how to fetch them is out of the scope of this project.

I encourage you to create a separate project on GitHub with any code you write that deals specifically with the issues sorting out which URL to use for images on the GigaPan site. That will allow you to maintain that code and react to any changes made by GigaPan to their site without affecting this plugin.

Thanks and good luck!