UniversalViewer
Download "Current view" sometimes returns wrong region of image
The download option "current view" seems subject to problems. For example, try loading this manifest:
http://digital.library.villanova.edu/Item/vudl:449131/Manifest
Zoom in a bit and move the image so that only the bottom right corner is visible in the display area. Now attempt to download "current view." The resulting image seems to come from somewhere near the top left of the image.
It has also been reported that UV occasionally generates completely invalid out-of-range coordinates which cause the IIIF image server to return an error.
No idea if this is relevant, but there's a bug in the search annotations in 2 up mode, where Tom alludes to the reason being a difference in scale factors.
Your images report themselves as 2088x3000, but the canvas size is 1562x1087.
If i modify your manifest and change the canvas size to 2088x3000, I get the correct view downloaded.
I'm not sure whether the UV handles it, but there is no requirement for the canvas dimensions to match the dimensions of the image resources that annotate it, or the image services on those image resources. The canvas dimensions provide a coordinate system for the "abstract" canvas space, whereas the image dimensions are pixel width and height of the particular image annotation. The image service for that image resource could report yet another width and height.
In practice, most of our canvases have one image that annotates the entire canvas, with one image service of the same dimensions as the canvas. But that's just the happy path. The sizes could be different, or the image could annotate a particular #xywh region of the canvas, not the whole thing (e.g., a scrap of manuscript is all that survives).
Thanks for the input. It seems like this problem comes from two factors:
1.) There are some edge cases on our end where TIFF dimensions and derivative JPEG dimensions don't match up. The image server is serving from JPEGs and the manifest is selecting canvas dimensions based on TIFFs, thus allowing these occasional mismatches to cause problems.
2.) As @tomcrane points out, this shouldn't actually break the viewer, because the canvas dimensions and image dimensions are technically independent -- but right now the viewer is making assumptions about the canvas dimensions matching in several places (see also recent discussion about the numbers in the download dialog box).
So I think the bottom line is that this is a UV bug that needs to be fixed -- please let me know if I can also be of assistance in moving things forward!
@demiankatz - re point 2 above - to re-state slightly - conceptually what the UV needs to do is render the IIIF Canvas on the OpenSeadragon world, by determining what the canvas size should be on that surface and then applying one or more tile sources to OSD to actually draw it (i.e., annotate with images). The tile source(s) might be scaled to fill the canvas, or scaled to annotate only part of it. OSD is still only dealing with tile sources but the UV is applying Shared Canvas to determine exactly where and how big the tleSources are.
@irv, @edsilv - https://github.com/UniversalViewer/universalviewer/issues/119 is on the BL roadmap; might be a good time to address this.
All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.
This is still a bug in the latest UV 3. I can't figure out how to try to reproduce it in UV 4, as the "download current view" option is entirely missing when I load https://digital.library.villanova.edu/Item/vudl:449131/Manifest into https://uv-v4.netlify.app -- is that expected? Has the "download current view" option been removed entirely?
Update: I figured out why I couldn't see "current view" in UV4 -- it's because the option is disabled in 2-up view, which is active by default. When I switch to 1-up view, I can confirm that the problem still exists.