Download Current View - Errors when xy coordinates are negative

[terrywbrady]

UV version:

v2.0.2

I'm submitting a:

• [ x] bug report
• feature request => please use the user stories repo
• support request => Please do not submit support requests here, use stackoverflow

Current behavior:
If my current view of a canvas includes a negative value in the xy coordinates and I select "download current view" the image server request results in a 404 error.

Expected behavior:
If the negative values are not valid in an image server request, then those values should be set to zero before sending the request.

We have a second test server that is referencing an image server on a remote box. When we attempt to repeat this scenario in that configuration, the negative coordinates are set to 0. Does this sound surprising? We are hosting the same UV software on both boxes.

Steps to reproduce:
Open the following... note the negative coordinates.

https://repository.library.georgetown.edu/handle/10822/1044538#?m=7&c=0&s=0&cv=0&r=0&xywh=-2718%2C-2235%2C5435%2C4468

Click "Download Current View".

The negative values are passed in the request to the image server.

Not Found: could not resolve identifier: Keller__Box4_Folder37__10822_1044549__GTM-860903_B04_F37_00001.jpg%2F-2718%2C-2235%2C695%2C1000%2F695%2C1000%2F0%2Fdefault.jpg (404)

Related code:

// insert any relevant code here

Other information:

[terrywbrady]

Based on this issue, we are going to suppress the "download current view" option. It could be useful to add a configuration option to disable just the "download current view".

[edsilv]

Adding to the community call board for Open Collective prioritsation later today.

[irv]

Another duplicate of #464

we also have hit this in the past; after some discussion on IIIF slack we agreed it's an invalid request, and image servers shouldn't round to 0.

https://api.bl.uk/image/iiif/ark:/81055/vdc_100052180287.0x000001/-10,0,10,10/max/0/default.jpg

"X or Y must be unsigned"

We haven't seen this since upgrading to 2.0.2

[LlGC-szw]

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.

[ta1986]

I still see this issue in v4:
https://uv-v4.netlify.app/#?manifest=https://collections.nlm.nih.gov/iiif/nlm:nlmuid-101277645X1213-leaf/manifest
-> Single view -> zoom in/out a page -> Select download

@terrywbrady How do you disable "download current view" feature? Thanks

[terrywbrady]

@ta1986 , I no longer support this code, so I cannot remember how I disabled the feature.

[demiankatz]

As noted in @ta1986's comment above, there does seem to be an active problem here. I'm not sure if the v4 problem we're currently seeing is exactly the same as the originally reported bug, but I think further investigation is needed. I'm also seeing some strange behavior with the https://collections.nlm.nih.gov/iiif/nlm:nlmuid-101277645X1213-leaf/manifest manifest where the full-size download works correctly, but the 1000-pixel bounded box smaller download does not have the right aspect ratio and returns only the middle slice of the image. Not sure if this is a bug in UV or a problem with the manifest; I wonder if this behavior is related to the other problem in some way.

[ta1986]

Hi @demiankatz, iiif manifest canvas is the root cause. We don't have dimension information for all pages so we have to hard code the canvas to 0x0, 1x1, or 99999x99999. UV uses these numbers to calculate the download area instead of the actual size from the image server.
I guess we have to accept the issue until we reindex all page info Or UV switches download feature from canvas to full size from the API.