Synchronized zoom between slots

[markmatney]

The organization that is funding UCLA Library's Mirador project ("Sinai Palimpsests") are interested in this feature. Can anyone speak on the possibility of it being added to an upcoming release?

[aeschylus]

It's likely coming soon after 2.1, which is expected sometime in March. The roadmap after 2.1 hasn't been revisited since the wiki page was updated, so that will need to happen in the community call over the next month. That will bring that page up to date.

It is a high priority for a number of institutions, so "soon" is not disingenuous. It is relatively easy to implement (it was already in Mirador 1; see the implementation here), but the user interaction will require some vetting. Mirador one allowed locking particular windows together on a 1-by-1 basis. That pattern was problematic for many. Discussions since then have centred on a lock button for the entire workspace.

Other considerations include the exact nature of the "synchronisation". Different images have different resolutions, physical dimensions, and virtual aspect ratios. What should the mapping between one unit of horizontal motion be for one image to another with a very different aspect ratio? What if some images have associated physical dimensions but some don't. Some of these tradeoffs (which I was calling "lock profiles", or strategies) are noted in the implementation above.

[beaudet]

Please review the following design proposal for this feature. Mockups can be created after features are agreed upon.

Design Proposal For Pan/Zoom Locking (needs mockups)

Summary

Pan/Zoom locking of all slots in Mirador will be controlled by selecting a locking scheme from the top level menu. The locking scheme will control how follower slots’ origin point is to be aligned with the leader slot and how the panning and zooming will be scaled from the leader slot to the other slots. The following locking schemes will be supported:

• by initial view (default)
• by ruler

The maximum zoom level shall be the deepest zoom available for the active slot. Follower slots will be over-zoomed or under-zoomed accordingly. Similarly, the minimum zoom level shall be the level at which zooming out further is not possible for the leader slot and follower slots will be zoomed-out accordingly, respecting the alignment and scale of the locking scheme. The panning shall be scaled according to the locking scheme scale.

Lock Pan/Zoom by Initial View Configuration when Pan/Zoom Locking is Toggled On

• uses the center of the view port for alignment between the canvases in the slots and scales according to the portion of each respective canvas currently displayed in each slot

Lock Pan/Zoom By Ruler and/or Placement of Registration Pins

• The ruler feature shall be enhanced to default to using pixels as the dimension when no physical dimension data is supplied in the manifest
• There shall be two “pin-style” markers (pin1 – green and pin2 – red) available on the ruler that can be dragged onto the canvas to mark specific “registration” points. Once placed, these markers should only be visible when the cursor hovers over the ruler. The portion of the ruler where the pin would normally reside is replaced with the coordinates of the marker and a “X” icon for returning the pin back to the ruler. The distance between the pins is calculated and displayed on the ruler when both pins are placed.
• If images with different physical scales are placed onto the same canvas, the ruler shall be able to be toggled through all such scales
• when no ruler pins exist on one of the canvases involved in the scheme
  • [ ] ruler units are used for scaling and the origin is used for alignment
  • [ ] the physical scale can be used to map to pixels in the event that either the leader or the follower are using pixels as the unit and the other is using a physical dimension
• when the same color pin (or both pins) are placed on both canvases involved in the locking scheme:
  • [ ] when one pin is placed, the alignment of the images occurs on that pin color. Scale shall be by ruler units
  • [ ] when two pins are placed, alignment of the images and scale is determined based on the distance between the two pins on each of the canvases having pins

[markmatney]

I think having an option to toggle on/off "over- and under- zooming" would be nice, so that all canvases in a locking group would effectively have the same range of zoom levels available, and would always be at the same zoom level at any given time.

As far as "The portion of the ruler where the pin would normally reside", I am envisioning one pin at either end of the ruler.

(also, I have taken a shot at implementing a feature like this (which uses some of the 'lock profile' code from Mirador 1) on our fork, which could be a useful starting point for us. Right now it assumes that all windows in a locking group will have identical pixel-to-physical-unit ratios.)

[radpet]

@beaudet Manually panning and zooming is disabled to the slave slots right? Further more how we treat prev/next image controls Would you show us any mockups if you have already prepared some. I would like to see more about

Lock Pan/Zoom By Ruler and/or Placement of Registration Pins

[beaudet]

I was thinking that whatever slot is being manually panned/zoomed becomes the leader slot and the others the slave(s). On the surface, this doesn't seem like it would present any problems as the initialization of the scale, etc. would occur at the time the locking mode was first invoked.

As for switching images, I imagine that should automatically disable the locked pan/zoom selection. However, if you switched images then returned to the prior image, my understanding is that the new IIIF manifest layouts allows the last view of the canvas to be retained. I don't know if that's done at the canvas level or at the slot+canvas level, but if the later, perhaps each slot's view might be able to be retained and therefore you could return to locked pan/zoom mode if all preconditions are met.

What do others think? Is anyone able to take a stab at some mock-ups for this so we can further vet the ideas?

[markmatney]

Here is a demo of my implementation: https://www.youtube.com/watch?v=gqZRkTp4my0

It conforms to

whatever slot is being manually panned/zoomed becomes the leader slot and the others the slave(s)

but remains in a synchronized group when the image is switched to a different one inside the same object. However, if a new object is loaded into a window, that window is removed from the synchronized group.

[radpet]

@markmatney That is really cool :+1: . By the way I saw that the slave slots lag behind if you zoom/pan by few seconds. Are you using openseadragon's events with debounce?

[markmatney]

@radpet Yes, here is the original code in branch release2.1, and here is how I am doing the synchronization. I am annoyed by the lag, so any tips on how to make that go away would be appreciated.

[radpet]

@markmatney Have you tried to attach new handlers to the zoom/pan without debounce?

[markmatney]

No, I have not. I could try that. Thanks!

[markmatney]

Last week I moved the code for my implementation of this feature to its own branch off of the upstream 2.1.2: https://github.com/UCLALibrary/mirador/tree/synchronized-window-groups-feature

I am compiling notes for the feature (usage, current issues, discussion, etc.) here: https://docs.google.com/document/d/1BuujLOLXO9XSeytduhYNi5jwjk0TM1U0ra_7q-2FV8k/edit?usp=sharing

[jpadfield]

Hi,

I just wanted to ask how this is progressing.

@markmatney I have seen one of your demos and this feature looks really great.

One thing I wanted to check is have you thought about mirroring your cursor as well? Basically when you move over the master image there is also a "slave cursor" on the slave images which would allow users to have a better sense of the comparison. This may not be needed and is slightly harder to implement.

You can see a public example of what I mean at: http://cima.ng-london.org.uk/iip/examples/newcomp.html

I should say that this is an old viewer, but it is still used in house and it would be great to replace it with the mirador viewer at some point in the future.

Another related question that has come up before, @beaudet also mentioned this in his post above, (and this would be related to knowing the relative resolution of a given image, which I think is in iiif) but I was not sure if this has been taken up, could a registered viewer do scaling on the fly ?

If I have two images, one is very high resolution and one is moderate resolution, of the same object, the images are registered but one is several times bigger than the other one. At the moment I often increase the size of the small images to match the size of the bigger image in order to present them in a registered viewer. How complex would it be to get Mirador to take an images relative resolution into account when the images are locked together, thus the smaller images would just start to pixelate when you zoomed in past a certain point, as noted in @beaudet comment. but the presentation would work and there would be no need to create and store an artificially big registered file.

This can often happen when examining paintings when one wants to compare and X-ray with a visible image with and Infra-red, etc.

I did look at the maths a few years ago, with example link I added above, it looked possible, but worked moved and I have not been able get back to it.

Thanks

Joe

[beaudet]

Joe, also see the Layers Tab feature #902 request currently being worked on by @radpet to support ConservationSpace overlays of registered images. It will be possible to resize and translate two images so they are superimposed on one another, then to adjust the transparency.

[jpadfield]

@beaudet looks good, overlays can be very useful, however I would say that the feed back I have got from practitioners actually using complex image viewers is that they have preferred side by side comparisons, for actual work. I think there is benefits of both approaches particularly for public engagement.

[beaudet]

I agree. Pan/zoom synchronization of slots is also an important feature for ConservationSpace.

[markmatney]

Hi @jpadfield, thanks for the feedback! I have not been actively developing UCLA Library's fork of Mirador for several months now as a result of being placed full-time on a different project, but regardless, I don't anticipate much of my code (as is, at least) will end up in the main repository. The windowing system controller is currently going through a massive overhaul (the code for which has it's own repository, often reffered to as IIIFML) and will be structured quite differently in upcoming releases.

I had not thought of the cursor mirroring feature but that is a good idea. Basically it would consist of event listeners that watch for mouse actions over a window.

• On mouseenter, render an overlay on top of each synchronized canvas.
• On mouse move, change the position of each overlay according to the leader.
• On mouseleave, remove the overlay.

I would dig into the OpenSeadragon APIs for this (if 2.x.x, http://openseadragon.github.io/ should suffice for documentation; if 1.1.1, clone the documentation repo and go back in time - my HEAD is at e08d70d425e964fe83e81eb08407f24049ad645c fwiw). Looking at the 1.1.1 docs you'd want to check out the Overlay object as well as the overlay methods on OpenSeadragon.Viewer (addOverlay, etc.) -- 2.x.x may have a slightly different API. Since in our fork, the OpenSeadragon object is a member of ImageView, I'd put the event listeners in ImageView.bindEvents. These listeners would publish events via an EventEmitter object to the LockController, which could call this function to add, update, and remove overlays on each OSD instance (one per ImageView).

The zoom matching feature you mention would be a bit more difficult to implement IMO, but again would need to make use of the OSD APIs. In our fork, zoom synchronization happens here. You could have a similar function that implements your desired "zoom matching" scheme, and have a UI element that indicates that this is the desired action when a user zooms on synchronized, "matched", windows (calling this function). Here's some ideas from the first version of Mirador.

[markmatney]

(despite not being active as of late, I do still plan to take part in the discussion of this feature -- and of Mirador as a whole -- as time permits, and to always be available for questions about UCLALibrary's fork in particular)

[markmatney]

Just want to note that I've made available a plugin that implements this feature, if anyone wants a way to deploy it in the meantime while we come to a consensus about how to bring this feature into core. (Please feel free to submit issues and/or PRs on that repo!)

[camillevilla]

This ticket is being closed as part of the Mirador 3 issues review. We encourage all Mirador 2 implementers to try out Mirador 3 and leave feedback in new tickets.