Issue with DZI processing

[malaterre]

There is an inconsistencies when constructing URL for the DZI method. The configure function reads as:

dziPath = url.split('/'); dziName = dziPath.pop(); dziName = dziName.substring(0, dziName.indexOf('.'));

while it should read:

dziPath = url.split('/'); dziName = dziPath.pop(); dziName = dziName.substring(0, dziName.lastIndexOf('.'));

Thanks

[hankcurt]

I can confirm this bug report.

The issue occurs when there is more than one dot in the file name. In that case, the current code in Seadragon 0.9.84 truncates the name at the first dot instead of just removing the portion after the last dot, which is the behavior that is desired. This bug causes deepzoom requests to IIPImage Server to fail because the URL for the server is formatted as: /iipsrv.js?DeepZoom=/path/to/image.tif.dzi

Seadragon then requests the tiles using /path/to/image, which fails because it should be /path/to/image.tif

I tested the fix posted above by malaterre by changing line 5706 in SeaDragon 0.9.84 to: dziName = dziName.substring(0, dziName.lastIndexOf('.'));

After this change, SeaDragon made correct tile requests to IIPImage

Thanks

[hankcurt]

In the previous comment, the SeaDragon version number should read 0.9.82.

[thatcher]

I have this in my local trunk, will commit it very soon and ping this ticket. thanks for the catch

[thatcher]

Fixed in trunk and on the web for review. the current site is http://thatcher.github.com/openseadragon

Please let me know if still leaves the issue unresolved.

Thanks, Thatcher

[jottevanger]

Hi. This issue appears to be back in 1.1.1. I have reverted to 1.0.0 but when I tried 1.1.1 I was also seeing requests for tiles in the form:

/fcgi-bin/iipsrv.fcgi?DeepZoom=/media/media-372637.tiff_files/11/0_0.jpg?DeepZoom=/media/media-372637.tiff.dzi

as opposed to the correct form:

/fcgi-bin/iipsrv.fcgi?DeepZoom=/media/media-372637.tiff_files/11/0_0.jpg

Hopefully it has a similarly simple fix, but the lines above, setting dziName, don't appear to be present in 1.1.1.

Thanks, Jeremy

[iangilman]

Looks like we're mishandling the query string case. This is likely due to https://github.com/openseadragon/openseadragon/pull/378. Would you be up for adding some logic that supports your case?