An open-source, web-based viewer for zoomable images, implemented in pure JavaScript.
Using openseadragon.min.js. 739 points to a line that’s commented out
//# sourceMappingURL=openseadragon.min.js.map 🤷♀️
I believe the Chrome Violations are just there to warn you that some block of code, the
load handler in your case, is taking too long @tdiprima , they shouldn’t affect your code too much. And about line 739, I checked the openseadragon.js source file that Chrome loads, looks like it’s just referring to the OpenSeadragon initializer as the thing that’s causing all the trouble 😁:
@PrafulB the
open behavior you described sound strange. Can you share a repro?
In other news, the time has come for OpenSeadragon memes! https://twitter.com/openseadragon/status/1433109997710295043
Never mind @iangilman , it was completely my screw-up. I was running a
querySelector on the document to find my canvas on the page and deleting the innerHTML of one of its ancestors, but because I moved some things around recently, the OSD canvas would get returned instead. Since it wasn’t part of the page anymore, the width and height of the canvas would get reduced to 2 (not sure why that is), and it would ask for just the thumbnail, render it and raise the fully-loaded-change event. I was confused because I could see my container on the page, and I never thought to check if the canvas was still there. Anyway, mystery solved! (for now)😵💫
In other news, the time has come for OpenSeadragon memes! https://twitter.com/openseadragon/status/1433109997710295043
Best I could come up with 😬:
I think there's a promising future for OSD memes :)
Glad to hear you sorted out the issue as well!
@iangilman The ability to change the shader is not quiet the anticipated outcome. I was referring to if I have the plugin loaded like this
seaGL.vShader = '../fileV.glsl';
seaGL.fShader = '../fileF.glsl';
seaGL.init();
function buttonClick() {
seaGL.fShader = '../fileF.glsl';
seaGL.shade();
}then I have a button to change to a different fragment shader in the same context, how would I change the code if I have already ran the seaGL.init()?
@iangilman basically — multi-image says to pass an array of tilesources to either viewer.open() or upon instantiation. BUT — what if some of those tile sources are custom? Custom tilesource says to specify a function named getTileUrl. Plus height and width. Are you supposed to do both methods? If so, why?
@iangilman I think I may have answered my own question, but — I think all I have to do is pass an array to OpenSeadragon instantiation, the array looking something like...
[{
// LET’S SAY THIS IS THE MAIN IMAGE
tileSource: 'my-image.dzi’,
x: 5,
y: 0,
width: 10
},
{
// LET'S SAY THIS DEFINES THE CUSTOM TILESOURCE
height: HEIGHT,
width: WIDTH,
getTileUrl: function( level, x, y ){
return URL;
}
}]
Isn’t the option always
tileSources when used on instantiation @tdiprima ? The docs don’t mention a tileSource option.
For IIIF, I think the format of the tileSource itself is different: https://openseadragon.github.io/examples/tilesource-iiif/ . You should be able to pass in a custom
getTileUrl to it as well if you want to just as you have here, since the IIIFTileSource class extends the TileSource class.
@PrafulB yes, you’re right. Before, I was doing
I know — I’ve got a few questions rolled into one, and it’s a little confusing. I’m trying my best to iron it all out. But - do you know what I mean? About having to do both?
addTiledImage, which has a tileSource, but then I changed it, and I forgot. Good point about the IIIFTileSource class extending the TileSource class. I just want to make sure I’m not doing it wrong. You know? Like -- if a custom tile source is served via IIIF... I would think that the IIIF would take precedence. And I would not have to do getTileURL. But I am wondering if there is a reason I should do the getTileUrl as well as specify the IIIF tileSource.I know — I’ve got a few questions rolled into one, and it’s a little confusing. I’m trying my best to iron it all out. But - do you know what I mean? About having to do both?
I agree, you shouldn’t need to define your own
getTileUrl since OSD will automatically format the requests for tiles as per the IIIF specification. I’ve never needed to add in a custom getTileUrl in my IIIF use case, but I guess it’ll depend on the tile server implementation.
Btw @tdiprima I see you are at Stony Brook BMI, are you by any chance using the tile server written by Erich Bremer?
2 replies
@tdiprima yeah, the parameters you can pass into
open and addTiledImage and the tileSources option are pretty confusing because there are so many possibilities! The style of parameter you can pass into addTiledImage is the most robust, giving you all the possible features. You can also pass exactly that same style (either as a single object or as an array of objects) into open or the tileSources option. But those two also allow you to pass in just the thing you would give to the addTiledImage parameter named tileSource, again either as a single item or as an array.
@/all We started this Gitter a long time ago, and it seems to be working well, but nowadays I feel people are using Discord for this sort of community. What do y'all think? Should we start an OpenSeadragon Discord? No need to close down this Gitter, of course… We can have both and see what people like.
I just stumbled across Open Sea Dragon and it seems like a really interesting tool. I'm interested in building an image wall made up of multiple zoomable images. Each image will animate in and out rotating from a pool of images. For now though, I'm interested in just getting started. Are there any intro tutorials? Also I saw that there were multiple zooming image formats. Are any recommended over others in terms of performance?
@b0ot_twitter Welcome! This page is kind of our intro tutorial: http://openseadragon.github.io/docs/
I'm actually working on a full course for OSD, but it won't be ready for a number of months. https://github.com/openseadragon/openseadragon/discussions/1990
How big are your images? If they are small enough you might not need a tiled image format like DZI. At any rate, DZI is an open format and well-supported outside of Microsoft, so the Microsoft announcement doesn't really have any bearing on OSD.
For converting to DZI there are a lot of options (http://openseadragon.github.io/examples/creating-zooming-images/), but I prefer VIPS.
@iangilman Thank you for the warm welcome and information!
Truthfully, I am just starting to explore how realistic it is to create this idea that I had so there are a lot of unknowns currently. My guess is that the individual images will vary between HD and 16K in resolution.
These individual images would be combined into a wall where a large number would be visible... say 25-75 images.
I thought it would be really interactive/enjoyable if the user could pause the wall at any time and zoom in on any individual image.
My main concern was the user experience in zooming as most implementations of zooming I have seen were clunky/non-intuitive but the openseadragon viewer examples were super smooth.
I'm also seeing if I can layer these images in creative or even 3d ways. I want the wall to feel alive, constantly moving, images changing in and out from a large stockpile.
@b0ot_twitter sounds awesome! You can definitely do something like that with OSD. I imagine you'll want to use the "multi-image" features (http://openseadragon.github.io/examples/multi-image/) and do all of the image positioning that way. OSD isn't literally 3D, so you can't tilt the images, but you can certainly layer them.
You can see in https://iangilman.com/openseadragon/flickr/ an example of positioning/sizing the images dynamically. Not exactly what you are planning but similar in some ways.
OK @PrafulB (and anyone else who is interested), I've created a Discord for OpenSeadragon… Here's the invite: https://discord.gg/Ygwap8UrGC I don't really have it set up in any way; I figure we'll figure it out as we go :-)