ProjectMirador / mirador

An open-source, web-based 'multi-up' viewer that supports zoom-pan-rotate functionality, ability to display/compare simple images, and images with annotations.
https://projectmirador.org
Apache License 2.0
548 stars 258 forks source link

feature request: allow one canvas to be overlaid on the others with transparency control #699

Open beaudet opened 8 years ago

beaudet commented 8 years ago

REPLACED BY #902 - should probably close this issue

The ConservationSpace project needs to support ad-hoc overlay of one image on top of another - think x-ray or infrared on top of visible light. Sometimes these images are computationally registered, cropped, resized together to perfectly align their pixels, so overlaying is easy, but for many smaller institutions, this is not feasible. Therefore, we need an image overlay approach that supports both ad-hoc overlay as well as overlay of registered images.

I propose that when viewing a manifest in "image" mode, that it be possible to mark one of the canvases as a transparency that is then overlaid on top of any other canvas selected. When that other canvas is selected, a cross-fader control and a pan/zoom lock control appear in the interface. The cross-fade control would adjust the transparency of the overlay as well as the selected canvas. When unset, the pan/zoom lock permits a viewer to fine tune the relative location of the two canvases within the view port until they are aligned, then the user can lock the pan/zoom to allow the canvases to be explored together as one.

Modeling overlays within the same canvas is also feasible and would work reasonably well for registered image sets, although adjusting the zoom level and location of a canvas prior to overlay (ad-hoc) would not be possible with the existing tools and creating the capability to move and re-size images within a single canvas seems quite a bit more labor intensive than the capability I'm proposing here.

See image below for concept. In this case, the viewer had previously selected the "infrared" image as the transparency and then selected to view the visible light. Although the images have been centered on the eyes, you can see that the aspect ratio is a bit off between the two images - this is not atypical of images that would be encountered in the ad-hoc scenario, so moving canvases with respect to each other in the Mirador tool is critical for the overlay feature we're seeking.

Finally, another method of comparing images is to put the images side-by-size in two different slots (in the case of ConservationSpace, two different image widgets since we intend to have only one slot per image widget). Locking the pan/zoom controls between slots would be helpful when exploring such images, but certainly not critical since an overlay is not in play in such scenarios.

This issue is related to https://github.com/IIIF/mirador/issues/632 and probably https://github.com/IIIF/mirador/issues/411 and https://github.com/IIIF/mirador/issues/223

cspace_mirador_canvas_overlay

=== an alternative slot-based approach starts here ===

Another approach we considered involved merging slots together as tabs in the same window and allowing them to be superimposed on each other. See screenshots below. We are leaning away from this approach because it's complex and we're moving in the direction of using Zen mode and enforcing a one slot and one Manifest per iDOC image widget constraint. We can do this because the functionality of Mirador slots is largely replaced by ConservationSpace's "Image Widget".

mt1 mt2 mt3 mt4

doldman commented 8 years ago

Is there any more news on this! This is quite an important requirement.

beaudet commented 8 years ago

features to control transparency at the canvas level are being addressed through other tickets. Features to add additional image resources to a canvas (the start of canvas authoring), move it around w.r.t. other image resources, etc. are being considered as part of #902