These are chat archives for openseadragon/openseadragon

3rd
Apr 2015
Jeremy Shipman
@jedateach
Apr 03 2015 02:28
is there an easy way to convert between different kinds of units?
i.e. physical, vs %, vs screen etc
I’ll try viewport.pointFromPixel / pixelFromPoint
Jeremy Shipman
@jedateach
Apr 03 2015 02:49
deltaPointsFromPixels did the trick!
Jeremy Shipman
@jedateach
Apr 03 2015 04:03
Ok, I’m actually a little lost as to how to implement what I’m doing
I’m currently trying to make a overlay draggable
My handler functions, fired by this.mouseTracker:
$.AreaSelector.prototype = {

    pressHandler: function(event) {
        this.dragging = true;

        this.dragOrigin = event.position.clone();
        this.rectOrigin = this.rect.getTopLeft();
    },

    dragHandler: function(event) {

        offset = event.position.minus(this.dragOrigin);
        offset = this.viewer.viewport.deltaPointsFromPixels(offset);

        this.rect.x = this.rectOrigin.x + offset.x;
        this.rect.y = this.rectOrigin.y + offset.y;

        this.snapToGrid();

        //TODO: this.respectViewport();

        //update position
        this.viewer.updateOverlay(
            this.element,
            this.rect,
            $.OverlayPlacement.CENTER
        );
    },
Jeremy Shipman
@jedateach
Apr 03 2015 04:09
@iangilman feel free to give any pointers as to what to adjust.
Whilst dragging the element doesn’t remain exactly under the mouse, and it appears to constantly switch between two different positions.
I think my issues might be something to do with taking the event position information - which is all relative to the draggable element (via it’s mouse tracker) …when in fact I should be getting the drag origin data from the viewport. I’m not sure how to access that data however.
Jeremy Shipman
@jedateach
Apr 03 2015 04:15
FYI: I’m working mainly with the decimal position values (between 0-1) as my base coordinates. I’m not sure what is the best system to use.
Mark Salsbery
@msalsbery
Apr 03 2015 15:38
@jedateach Not seeing coordinate issue yet, but I would use dragEndHandler instead of releaseHandler :)
@jedateach lso, I personally prefer during drag operations to keep everything in platform/element coordinates (generally pixels) for simplicity and only convert to logical 0.0-1.0 coordinates in dragEndHandler
lso = also
Mark Salsbery
@msalsbery
Apr 03 2015 15:44
…or in your case convert to logical coordinates right before the call to updateOverlay instead of before calculating the new rect.
Ian Gilman
@iangilman
Apr 03 2015 16:15
@jedateach @msalsbery Hmm...I always go the other way and convert to viewport coordinates as soon as possible. For instance in the pressHandler I would immediately do this.viewer.viewport.pointFromPixel(event.position), and likewise in the dragHandler.
That way you know you're always correct even if the viewport moves during the drag (say, if you're allowing people to scroll while they drag outside the bounds)
Mark Salsbery
@msalsbery
Apr 03 2015 16:17
Heh yeah, I’m just used to it from way back when performance was an issue, and doing resizes of complex annotations require many computations for the displayed elements, but the logical coordinates are only needed when the operation is complete :)
Ian Gilman
@iangilman
Apr 03 2015 16:17
Fair enough :)
Stephen Parsons
@stephenrparsons
Apr 03 2015 18:34
Hi all, I've created this viewer for layered datasets: http://stephenrparsons.github.io/layered-dataset-viewer/
We are looking to redo it with support for tiled images a la openseadragon. Basically we need to control two openseadragon instances at once and allow clipping so that you can see through a region of one to the other. Does anyone have any advice on how to approach this?
Ian Gilman
@iangilman
Apr 03 2015 20:02
@stephenrparsons Sounds cool! You'll probably want to use the new multi-image support that's on master. You can stack images on top of each other.
What kind of clipping? You can use PNG images with transparency, if you have complicated regions. We also support a super basic rectangular clipping definition.
Stephen Parsons
@stephenrparsons
Apr 03 2015 20:09
Circular clipping with a moving window (around the mouse) at minimum. Complicated regions are a stretch goal for now. Basically looking to recreate the aforementioned tool, just with tiled images. Thank you for the advice! I'll check it out.
@iangilman
Ian Gilman
@iangilman
Apr 03 2015 20:12
Yeah, we definitely don't support clipping at that level. You could probably add it in, though.
@stephenrparsons take a look at openseadragon/openseadragon#627 for inspiration
Jeremy Shipman
@jedateach
Apr 03 2015 20:38
hmm. I’m confused as to why this.viewport.getBounds() returns a rect that is the same height as my image, but wider than it
Ian Gilman
@iangilman
Apr 03 2015 20:39
@jedateach Is there white to the left and right of your image in the viewer?
Jeremy Shipman
@jedateach
Apr 03 2015 20:40
yes
when it starts
Ian Gilman
@iangilman
Apr 03 2015 20:40
That's why
The viewport bounds is whatever is currently visible in the viewer
Jeremy Shipman
@jedateach
Apr 03 2015 20:41
ok, i need the image bounds then i guess
Ian Gilman
@iangilman
Apr 03 2015 20:42
As in viewer.world.getItemAt(0).getBounds()?
That'll always be the exact location of the image in viewport coordinates regardless of where you have zoomed to
Jeremy Shipman
@jedateach
Apr 03 2015 20:43
yep, I’m going to make it a parameter you pass in to the AreaSelector: boundary
Ian Gilman
@iangilman
Apr 03 2015 20:43
Sounds good
Jeremy Shipman
@jedateach
Apr 03 2015 20:46
happy easter btw!
Ian Gilman
@iangilman
Apr 03 2015 20:46
Likewise! All the little ones in the neighborhood are abuzz
Jeremy Shipman
@jedateach
Apr 03 2015 20:56
there is no getBounds function on a TileSource … should it be getTileSize?
Ian Gilman
@iangilman
Apr 03 2015 20:57
A tile source has a size but not bounds, because you can't position it
Jeremy Shipman
@jedateach
Apr 03 2015 20:58
hmm. I’m guessing new Rect(0,0,1,1) would suffice for now
Ian Gilman
@iangilman
Apr 03 2015 21:01
That would be in viewport coordinates, if it's a square image
The tileSource just speaks in image coordinates. That value is the dimensions property
Jeremy Shipman
@jedateach
Apr 03 2015 21:04
ok, and I’m assuming 0,0 will be the top-left corner of the image
Ian Gilman
@iangilman
Apr 03 2015 21:04
Relative to what?
You mean the tile source or the tiled image?
The tile source is not positioned
Jeremy Shipman
@jedateach
Apr 03 2015 21:05
uh… whats the difference?
Ian Gilman
@iangilman
Apr 03 2015 21:05
And the tiled image is positioned, so it goes wherever you put it
Jeremy Shipman
@jedateach
Apr 03 2015 21:06
does ‘tiled image’ have a class?
Ian Gilman
@iangilman
Apr 03 2015 21:06
All the tile source does is define how to get the tiles...it doesn't have anything with drawing them to the screen
Jeremy Shipman
@jedateach
Apr 03 2015 21:06
I see
Ian Gilman
@iangilman
Apr 03 2015 21:06
Hmm...I think I assumed you were working off of the master branch, but maybe you're using the latest release? Sorry to be confusing if that's the case
(One more reason for us to finally release that branch)
Tiled image is a new class in the master branch
So yes, in OSD 1.2.1 0, 0 is the top left of all images
Jeremy Shipman
@jedateach
Apr 03 2015 21:08
ah right. I think I’m just on the latest release
Ian Gilman
@iangilman
Apr 03 2015 21:09
Cool. That's fine...I just was confused
Jeremy Shipman
@jedateach
Apr 03 2015 21:09
any eta on next release. I should probably just start working with master for this kind of dev work I guess
Ian Gilman
@iangilman
Apr 03 2015 21:09
So it'll be 0, 0 in the top left, the width will always be 1 and the height is based on the aspect ratio
Master is ready to release already...I'm just preparing some examples...that's all that's holding it up
Jeremy Shipman
@jedateach
Apr 03 2015 21:11
:+1:
Stephen Parsons
@stephenrparsons
Apr 03 2015 22:57
@iangilman would it be plausible to have each layer in a different div? I admittedly know very little about frontend tools as you may be able to tell ;)
Ian Gilman
@iangilman
Apr 03 2015 23:58
@stephenrparsons OSD does all of its drawing into a single canvas, so no it wouldn't make sense for them to be separate divs
Unless you want it to stack two OSD viewers on top of each other, but that would have its own share of problems
Why do you want them in separate divs?