These are chat archives for openseadragon/openseadragon

5th
Oct 2017
Tammy DiPrima
@tdiprima
Oct 05 2017 15:24

@iangilman, great, thanks. I actually do have a question. I’m still trying to figure out how folks design these things, based on this multi-image example code here:

viewer.addTiledImage({
    tileSource: 'my-image.dzi',
    x: 5,
    y: 0,
    width: 10
});

I don't have a dzi image, but even if I did… I feel like outside the API docs, there is a piece of this that I don’t understand. Like, does OSD make certain assumptions based on the width, height, tile size?
Also, like, take this for example:

    tileSources:   {
        height: 512*256,
        width:  512*256,
        tileSize: 256,
        minLevel: 8,
        getTileUrl: function( level, x, y ){
            return "http://s3.amazonaws.com/com.modestmaps.bluemarble/" +
                    (level-8) + "-r" + y + "-c" + x + ".jpg";
        }
    }

That's from custom tile sources. Why are we counting backwards? (level - 8) Other than walking through OSD code itself, is there something that explains how OSD works?

Samuel Allen
@dehuszar
Oct 05 2017 16:27
Hey all, I'm trying to do some overlay-shape transformations inside the OSD canvas. The shape is an SVG and will have translations and rotation on it (which I am able flatten back into osd coords after some functions get run). I'm having some trouble getting drag event changes to translate into the viewport coord system. I've tried using the pointFromPixel/pixelFromPoint to translate back and forth, but the tool we are using for handling drag events give us a plus or minus pixel-change value. Is there a way to convert an arbitrary pixel number i.e. -8px into the OSD coord system? Or would I just divide by the source image pixel dimensions?
Ian Gilman
@iangilman
Oct 05 2017 16:44
@tdiprima Yeah, I wonder if we need some additional instruction on multi-image specifically. Anyway, I think one source of confusion is the width in the two examples you give. In the first example, the tileSource is just the one string, and the other variables (x, y, width) are viewport coordinates for where to put the image. In the second example, the entire object is the tileSource; there's no additional information about where to put the image. In that example the width is how many pixels there are in the image and has nothing to do with how it's laid out in the viewer.
Part of the confusion comes from the fact that you can pass in either a tile source or a "tiled image spec" to either of those functions, and it'll figure out from context what you're doing. If the object you pass has a tileSource property, it's a "tiled image spec" which can include things like the x, y, width in the first example.
Of course another option is to wait until the tiled image is loaded and then position it via its methods afterwards.
Ian Gilman
@iangilman
Oct 05 2017 16:49
As for why the level - 8, OSD generally assumes a DZI-style pyramid, where the smallest level is level 0 and is generally 1 pixel square or so. That particular code example is for the blue marble data set, where their level 0 is more like 256 pixels square, so we have to convert our levels to their levels. In other words OSD level 8 translates to blue marble level 0; OSD level 9 is blue marble level 1, etc.
Tammy DiPrima
@tdiprima
Oct 05 2017 17:09
@iangilman yeahhh… exactly the thoughts rolling around in my head. Thank you! for the explanation. And thanks for clearing up my confusion — you were right, I was misreading the tileSource versus tileSources and getting confused.
Ian Gilman
@iangilman
Oct 05 2017 17:10
@dehuszar Are you using the SVG overlay plugin? Anyway, yes, for just arbitrary numbers you want deltaPointsFromPixels/deltaPixelsFromPoints.
@tdiprima We could probably use some better docs on that, and also maybe that API could be a little more explicit
Samuel Allen
@dehuszar
Oct 05 2017 17:11
@iangilman I am not. I was unable to get it to work the way I wanted (though I can't remember why at this moment). I've manually injected a full-screen SVG object and am passing the scale / transform values to it. I'll give deltaPointsFromPixels a shot, thanks!
Ian Gilman
@iangilman
Oct 05 2017 17:12
@dehuszar I see... well, if there's something that can be done to improve that plugin, let me know. At any rate, glad you got something that works :)
Tammy DiPrima
@tdiprima
Oct 05 2017 17:13
@iangilman sure! When I finally “get it” I can run it by you and contribute to the docs.
Ian Gilman
@iangilman
Oct 05 2017 17:13
@tdiprima That would be wonderful! :)
Tammy DiPrima
@tdiprima
Oct 05 2017 17:13
:)
Samuel Allen
@dehuszar
Oct 05 2017 17:19
@iangilman Just took a look. The issue is that I needed the ownership of the <g> to be an Ember component, and not an internally generated DOM element
Ian Gilman
@iangilman
Oct 05 2017 17:20
Gotcha. So if the plugin allowed you to pass the <g> in, maybe that would take care of it?
Samuel Allen
@dehuszar
Oct 05 2017 17:22
Yes, that might do the trick. Not sure if maybe some React users have seen similar issues and already worked around them, but I'm basically just using the viewer.viewport getZoom and containerInnerSize dimensions to pass the scaling values in when it detects the resize event firing. It would probably be a faster animation if I were able to use the native OSD/svg-overlay functions, but it has been an acceptable work-around thus far
I can access the dynamically assigned id that Ember gives the component when it's created, so that might be enough for the overlay plugin to bind to
Samuel Allen
@dehuszar
Oct 05 2017 17:32
The g and the child svg objects often won't exist when the tiled image is first rendered. We are using the SVG shapes to annotate areas of the image, so some will have them, some won't
Ian Gilman
@iangilman
Oct 05 2017 17:34
Well, the SVG plugin is pretty simple, so there's probably not that much of an advantage for you to use it now that you've built your own (except that you can get any future fixes)
You can delay applying the plugin to your viewer until after you've loaded the SVG objects; I think that's already in place
Samuel Allen
@dehuszar
Oct 05 2017 17:38
The animation speed would probably be the primary benefit. I'm using computed properties to scale the g element, so the extra step of requesting updated values from the viewer every time the event fires is probably not as efficient as what the svgOverlay plugin does. I might take another pass at it later. I've learned a lot since the initial implementation of this over a year ago.
The main issue is that I need a way to inject the shapes which are also ember components.
I should be able to reverse engineer some of this.
Ian Gilman
@iangilman
Oct 05 2017 17:44
@dehuszar Cool... well, it'd be great to have the plugin support Ember/React/etc. scenarios :)
Samuel Allen
@dehuszar
Oct 05 2017 17:49
It actually works pretty well. I'm mostly just setting up the viewer as a parent component, and everything happens inside. It's just when the library or plugins start creating their own DOM elements and event listeners, as the framework can't keep track of changes on them as easily.
I'll see if I can whip something up
Ian Gilman
@iangilman
Oct 05 2017 18:15
@dehuszar Awesome :)
Samuel Allen
@dehuszar
Oct 05 2017 18:18
@iangilman ...so I just looked at the source for the plugin, and I've literally just ripped out the events from the overlay plugin and added them to my overlay component. I'm just skipping the node creation. I'll talk to my place of work to see if they mind me releasing a generic set of Ember addons for the viewer and overlay
I probably just need to optimize how my events get fired, and remove any business-specific logic
Ian Gilman
@iangilman
Oct 05 2017 21:10
@dehuszar Sounds good. As part of that are there changes that could be made to the regular plugin to make it easier for such specialized plugins without a lot of surgery?