The current 2-up implementation was developed from the British Library's materials - but in those cases the facing pages were already cropped and framed to give a consistent viewing experience, so the problem wasn't seen. I suspect it would have been before long.
What's happening currently The UV code is postitioning the recto tile source on the canvas so that it aligns with the top of the verso image, and adds a small gutter between them (the size of this gutter is configurable, the current value is the result of user testing at the BL). What happens next is down to the OpenSeadragon library [0] that we use to render the deep zoom images. Currently this is what is scaling the images to be the same width. We need to prevent it doing that.
Quick fix - The only metadata the UV has to go on is that the pair of images are the verso of one page and recto of the following page - and even that information is inferred from the sequence rather than explicit in the metadata (but see https://digirati.atlassian.net/browse/WDL-130 for how to improve this). The UV doesn't know the physical scale, or whereabouts in the image the pixels representing the physical page are. Under these circumstances we could solve 99% of the problems by explicitly scaling the images on the canvas such that their relative sizes are in the same ratio as the pixel dimensions of the original images, because we can usually assume that the images are at the same scale (pixels per physical unit).
Ed and I have been looking at this and logged an issue. [1]
"The UV should not dictate local photography processes, nor should we assume that the images need to be shaped to fit the needs of the viewer." I agree that the UV specifically shouldn't dictate photography processes - but the intended use of the photographs should, which might include representation in viewers. However, some of those issues could be solved by more metadata rather than new photography. For the current issue the metadata does not exist to identify where the physical page is within the pixels of the image, or what the physical scale is, and capturing that metadata would add expensive and time-consuming overhead to the workflow.
In the longer term it's worth considering what the Shared Canvas / IIIF Presentation data model allows us to do - you can then at least make decisions about metadata you might want to capture, or add later. That doesn't mean you could take advantage of these right now - the UV doesn't support them all yet (and neither does Mirador or any other IIIF viewer).
Physical Dimensions service [2] Mirador 1.0 used this to display a ruler that scales as you zoom in and out, and there's an open PR for this feature in Mirador 2.0. It could be added to the UV fairly easily. Knowing the physical dimensions of the image could give the viewer more information when scaling multiple images together, rather than just using pixel dimensions. That is, even if the pixels-per-inch for two facing pages is different, they could be scaled appropriately.
Support for "non-paged" viewing hint [3] [4] The DDS generates a "paged" viewing hint for a manuscript, which relies on the METS file sequence sticking to recto/verso/recto/verso/... (see https://digirati.atlassian.net/browse/WDL-130 for ways to improve this). However, many image sequences have fold out maps, endpapers etc that are not part of the sequence. We have a mockup of how what the UV might do when it encounters a non-paged canvas in a paged sequence [5].
IIIF is built on Shared Canvas [6] and Open Annotation [7], which together allow us to say quite a lot about the relationship between pixels and physical objects:
Annotating a canvas with part of an image If the source image capture the scanning bed, colour calibration cards and other bits and pieces, but you want the image annotations to show just the "page" area, you can describe the resource using an IIIF selector [8]. This allows a book-reader showing a sequence of canvases to use only the relevant region of the source image. The UV doesn't support this yet, and more importantly you'd need the pixel coordinates of the area of interest in the source image. But the model supports it if you have the data.
Annotating part of a canvas with an image Scenario 1: A leaf of manuscript has been damaged, only a few scraps survive. Each scrap has been photographed separately. The manifest defines a canvas, and the canvas can still be the target of annotations for transcription, commentary and so on (a copy was made in C15 so we have the text). The viewer can present the images of the scraps in the right place on the virtual canvas. A more extreme example of this (and a great use case for IIIF) is the Biblissima example [9] where a previously dismembered manuscript is digitally recombined. The illuminations were cut out of the manuscript and sold years ago. Instituion A holds the illuminations, institution B holds the manuscript with holes in it. Both make their material available via IIIF, which allows a viewer to put the pieces together again. Scenario 2: Multiple images of the same item - raking light / x ray / colour etc. In this case the viewer allows the user to toggle between different views (or merge them). This is a feature that the BL will need in the UV soon. [10]
[0] https://github.com/openseadragon/openseadragon [1] UniversalViewer/universalviewer#278 [2] http://iiif.io/api/annex/services/#physical-dimensions [3] UniversalViewer/universalviewer#209 [4] http://iiif.io/api/presentation/2.1/#viewinghint [5] https://docs.google.com/presentation/d/19v2I4JSTmKBPMsmOOVDdd5k0pnc4c2qxBmArZHDNCTQ [6] http://iiif.io/model/shared-canvas/1.0/ [7] http://www.openannotation.org/spec/core/ [8] http://iiif.io/api/presentation/2.1/#segments [9] http://demos.biblissima-condorcet.fr/chateauroux/osd-demo/ [10] UniversalViewer/universalviewer#119 (comment)
Other links for discussion:
Manifest illustrating image size issues: http://tomcrane.github.io/scratch/sc-demo/ms1.json
Reductio ad absurdum: http://wellcomelibrary.org/item/b19689755#?c=0&m=0&s=0&cv=53
With paging viewingHints: http://tomcrane.github.io/scratch/sc-demo/ms1-nonpaged.json