These are chat archives for openseadragon/openseadragon

20th
Jul 2016
sickrandir
@sickrandir
Jul 20 2016 14:48
Hi guys, I ran into a strange behaviour with openseadragon on safari (both in iOS and OSX).
In a viewer with multiple tiled images, sometimes one image disappear when panning (when the border of the image reaches the border of the viewer) or zooming (at certain zoom level the image completely disappear).
You can easily replicate the behaviour opening with safari this viewer and playing a bit with pan and zoom: https://differenthood.duckdns.org/#/products/44
Does someone has an idea of what is going on?
it doesn't happen with other platforms and browsers
Ian Gilman
@iangilman
Jul 20 2016 16:22
@sickrandir Wow, that's very strange! I can certainly reproduce it, but I have no idea why it would be happening. Very strange that it's just on Safari. File an issue?
What kind of scale are you using for the viewport coordinates? With things like this one thing to try is scaling up the coordinates to width equals 1000 instead of the usual 1.
I guess another thing to try might be using straight images (i.e. ImageTileSource) instead of DZI... not that I think there's any problem with DZI; just brainstorming variables to test
sickrandir
@sickrandir
Jul 20 2016 16:27
Basically the viewport coordinates are based on the size of the background image. If you think that normalize the size of the viewer using the size of the background image could fix it I'll try
Ian Gilman
@iangilman
Jul 20 2016 16:28
Looks like your DZIs have a tile size of 128... these days I'm recommending 512... actually, with the overlap of 2 you have I guess it should be 508. Again, that probably doesn't have anything to do with it, just noting things.
sickrandir
@sickrandir
Jul 20 2016 16:28
The current way helps me keep the position perfect since I use the same pixel position that I export from photoshop
Ian Gilman
@iangilman
Jul 20 2016 16:29
So your viewport coordinates match the pixel coordinates of the background image? Yeah, that should be great.
Still, if you want you could try dividing by 1000 or multiplying by 1000 just to see if it affects the problem
sickrandir
@sickrandir
Jul 20 2016 16:29
yes, that's what I'm doing right now
ah ok
just dividing by 1k
that's easy to try
so I'll try: 1 divinding by 1k; 2 generating dzi with tile size of 512; 3 use plain images
does it look good?
Ian Gilman
@iangilman
Jul 20 2016 16:31
Besides the issue? Yeah... I love the concept of being able to swap different parts out too!
So your sub-images have transparency, which means we're using the sketch canvas... so maybe the issue is the transfer from the sketch canvas to the main canvas
Another thing to try would be non-transparent sub-images (not that that's your solution, but just to isolate the problem)
sickrandir
@sickrandir
Jul 20 2016 16:34
I mean try those point to troubleshoot
Ian Gilman
@iangilman
Jul 20 2016 16:34
Oh yes... good summary of the things I've suggested
Another thing worth checking is try using smoothTileEdgesMinZoom: Infinity in your options when creating the viewer... it's possible the default setting for that feature is causing trouble
sickrandir
@sickrandir
Jul 20 2016 16:35
ok I'll try also that
Ian Gilman
@iangilman
Jul 20 2016 16:35
I'll let you know if I think of anything else!
sickrandir
@sickrandir
Jul 20 2016 16:36
before asking I googled a bit and run into this: openseadragon/openseadragon#381
could it be related?
Ian Gilman
@iangilman
Jul 20 2016 16:36
Doesn't seem like it but maybe so
To test that you'd use smaller images
sickrandir
@sickrandir
Jul 20 2016 16:37
yeah that limit seemed higher than my images
Ian Gilman
@iangilman
Jul 20 2016 16:37
Agreed
sickrandir
@sickrandir
Jul 20 2016 16:37
ok
I'll test in the next days and come back with some result
Ian Gilman
@iangilman
Jul 20 2016 16:39
Sounds good... I look forward to getting to the bottom of this!
LarissaSmith
@LarissaSmith
Jul 20 2016 18:25
I've run into a case where we need to change our crossOriginPolicy to "Anonymous" for a few tiledImages, leaving "use-credentials" as the default. TiledImages have support in the property declaration for crossOriginPolicy to be set individually, but when we add them through addTiledImage, that value is always inherited from the viewer. In getTileSourceImplementation, there is some code that checks for and sets crossOriginPolicy on the tileSource object that is passed in, but that value never makes it into the tiledImage that is added (it's passed into the TileSource constructor, which doesn't seem to have crossOriginPolicy as a property, so it gets lost). Was the idea to support setting crossOriginPolicy for a tiledImage through the tileSource? What is the best way to implement that feature?
Ian Gilman
@iangilman
Jul 20 2016 18:36
@LarissaSmith Looks like the crossOriginPolicy in the TileSource is just used by the ImageTileSource (because it loads the image ahead of time). That said, I agree that it should make it to the TiledImage of course... maybe Viewer.addTiledImage should check to see if the TileSource has a crossOriginPolicy and prefer that over the viewer's. Of course this would require the TileSource to retain the crossOriginPolicy it's given (if it's not currently doing that).
Are you up for making that fix?
@avandecreme might also have thoughts, as he presumably did the ImageTileSource portion
LarissaSmith
@LarissaSmith
Jul 20 2016 18:53
Sure, I can make the change. The TileSource doesn't currently retain the crossOriginPolicy it's given, so I'm not certain if we want to add it as a property or find another way to send the crossOriginPolicy to the viewer.
Ian Gilman
@iangilman
Jul 20 2016 18:58
@LarissaSmith Excellent. I guess whichever seems better once you dive into it? As far as I know, the ImageTileSource needing a crossOriginPolicy is kind of a special case, so if we don't need to add a crossOriginPolicy to TileSource in general that might be good
Also if crossOriginPolicy becomes a parameter to addTiledImage, that probably gives the most flexibility, because you can use it even for tile sources that are just URLs