Trouble with non-square source images and scaling methods

[Jondeen]

Hi!

First off - awesome job on these libraries - I massively enjoy working with it.

I was playing around with the library to make annotations on a scanned histology slide, and realized that the y-dimension was slightly off on everything I drew, and more off the further down on the image I made the annotations. The x-dimension was fine.

I believe this may be related to/similar effect of a bug I filed at https://github.com/msalsbery/OpenSeadragonImagingHelper/issues/4 . In essence, I suspect the scaling is made entirely on basis of one dimension - namely the x-dimension. When the image is non-square this causes problems.

On my 1920x1080 (full) screen the drawing group gets scaled by 1297.35 and not the 1080 as expected (height being the limiting dimension for containing the image within the window). 1080 / 1297.35 (=0.8325) also equals the ratio of height-to-width of the dimensions of the source image.

Please let me know if I'm doing things wrong here - that may very well be! My js is a bit rusty to say the least (-;

[Jondeen]

Here is an example of a functional patch (for me)

        var scaleW = viewer.container.clientWidth * zoom;
        var scaleH = viewer.viewport.contentAspectY * scaleW;
        info.node.setAttribute('transform',
            'translate(' + p.x + ',' + p.y + ') scale(' + scaleW + ', ' + scaleH + ')');
        };

[iangilman]

This shouldn't be a problem...you don't want to scale your horizontal and vertical differently, or you'll get distortions.

How are you determining where to position your overlays? Perhaps your math is off there? Do you have an example I could take a look at?

Here is something I'm building using this plugin:

http://iangilman.com/openseadragon/flickr/

All of the text is drawn with svg-overlay. I suppose it may seem a little funky because of the animation, but everything seems right and consistent at the top of the world and the bottom.

[Jondeen]

Hi!

I'll pull up some of my source for you tomorrow - for now I've verified by manually entering logical coordinate 1,1 and observing the svg end up way below viewport.

I will do some more testing tomorrow and let you know. Also i'm fighting my way along with hooks and preventdefaults... Are these documented somewhere? Ive found references to their implementations in the old issues stack, though having a hard time putting them in use.

Thnx for swift reply! The flickr navigator looks cool!

[Jondeen]

Ok, so while brewing my morning coffee it dawned on me that I may have fundamentally misunderstood the basis of the logical coordinate space. It is entirely relative to the x-dimension? Meaning that the logical height of the image is equal to height/width?

[Jondeen]

As promised, here is some code:

        var OSDInitParams = {
            id: "view",
            zoomInButton: "zoom-in",
            zoomOutButton: "zoom-out",
            nextButton: "next",
            previousButton: "previous",
            tileSources: tileSourcesArray,
            preserveViewport: true,
            prefixUrl: imagePrefixURL,
            showNavigator: true,
            showHomeControl: false,
            showFullPageControl: false,
            showReferenceStrip: true,
            referenceStripSizeRatio: 0.05,
            showRotationControl: true,
            animationTime: 0.5,
            blendTime: 0.1,
            constrainDuringPan: true,
            maxZoomPixelRatio: 1,
            minZoomLevel: 2,
            visibilityRatio: 1,
            zoomPerScroll: 2,
            timeout: 120000,
            debugMode: false,
            debugGridColor: "#000000",
        };

        viewer = new OpenSeadragon(OSDInitParams);
        OSDHelper = viewer.activateImagingHelper();

        function onClickHook(event) {
                event.preventDefaultAction = true;
                var phys_p = new OpenSeadragon.Point(event.clientX, event.clientY);
                var p = viewer.imagingHelper.physicalToLogicalPoint(phys_p);
                shapeCoords.push([p.x, p.y]);
                console.log("X: " + event.clientX + ", Y: " + event.clientY);
                render();
        }

[iangilman]

Yes, your coffee-brewing insight serves you well; the height is indeed height/width. We'll be adding a page soon that makes that clearer:

https://github.com/openseadragon/site-build/pull/62/files#diff-5328e592bce1c71bbca09d365f5ad715R1

As for how to work with OpenSeadragonImagingHelper, you'll have to ask @msalsbery… I don't know the details.

I'm glad you're finding this plug-in useful!

[msalsbery]

@Jondeen The imaginghelper functions handle the aspect ratio for the y coordinates so you don't have to.

What issue are you having with the code above?

[Jondeen]

@iangilman Nice! Never distrust the potency of fresh morning coffee.

Okay, I'm beginning to realise there are a lot of lots of different ways to implement listeners onto the viewer-element. I had issues with making your hook-library work, @msalsbery -- at all. Cough. Just double checked and now it does. Somehow. I will backtrack all my routines to figure out where the y-dimension starts to wander off. I'll come back to you on this.

Regardless, for sake of conformity and standardization, what is the recommended way to implement a mouse action listener method as of now?

[iangilman]

Well, if all you need is simple clicks or drags, just subscribe to the appropriate viewer events, such as:

viewer.addHandler('canvas-click', function(event) { ... });

If you need a bit more than that, toss an OpenSeadragon.MouseTracker on it. If you need more than that, use OpenSeadragonImagingHelper.

[Jondeen]

Thanks for good replies -- I'll update this once I figure out the nature of my demonic y-axis.