universalviewer icon indicating copy to clipboard operation
universalviewer copied to clipboard

Issue with downloading images with a width exceeding 65,535

Open nakamura196 opened this issue 2 years ago • 1 comments

I am distributing images with a width exceeding 79,508 through Cantaloupe and encountered an error when trying to download them using the viewer available at: https://uv-v4.netlify.app/#?manifest=https://gist.githubusercontent.com/nakamura196/71fc6f626313c581c5c570556344ba7c/raw/789057d873b644efdabea0e145c8b28566daea90/test.json

While the error in the link above arises due to exceeding the max_pixels setting in Cantaloupe, the error persisted even after I disabled the max_pixels setting (by setting it to -1) because the image dimensions exceed the JPEG specification.

In cases like this, would it be appropriate to set the "whole image" download option URL in Universal Viewer to /full/full/? I believe it might be a feasible solution.

However, please note that even if we set it to /full/full/, the error concerning outputting a JPG with dimensions exceeding 65,535 will persist. Internally, I'm considering redirecting /full/full/ requests to /full/max/.

nakamura196 avatar Sep 25 '23 08:09 nakamura196

Providing such a large region for dowload is also not safe. It take time to load this, and it can be a source for a DDOS attack.

The UV does take parameters maxWidth and maxHeight into account, when present in the profile of the info.json.

e.g. https://adore.ugent.be/IIIF/images/archive.ugent.be%3A018970A2-B1E8-11DF-A2E0-A70579F64438%3ADS.325/info.json

When present, the size parameter in the download uri for "full view" is cropped to these bounds. The "full" is not "full" indeed in this case, but that is also a reason why "full" was removed from the spec in version 3 and replaced by "max". IIIF viewers do not require such large region extractions, as all data is fetched in small tiles/regions anyway.

nicolasfranck avatar Mar 13 '24 15:03 nicolasfranck

Thank you very much for bringing this issue to our attention and for the detailed discussion. Based on the information provided and the solutions discussed, I believe we have a clearer understanding of the situation and potential approaches to address it. With the considerations around the max parameter and the practical implications of downloading very large images, it seems we've identified a viable path forward. Therefore, I'll be closing this issue. However, please feel free to reopen it if there are any further developments or if additional discussion is needed. Your contributions are greatly appreciated.

nakamura196 avatar Mar 17 '24 12:03 nakamura196