Mirador v2.x requesting size of "1," if slot is small enough leading to problems with 400 bad request response

[beaudet]

• I am the author or maintainer of this manifest: Yes
• URL: https://www.nga.gov/accademia/en/maps/Tempesta-Pianta-di-Roma/jcr:content/parmain/tombstone.viewer.html
• Manifest hosting institution National Gallery of Art

Observed behavior

• Description: Before I applied a temporary patch to our IIP Image server, the URL above when loaded in a small size like that depicted in the screenshot, fetched a IIIF full region with a size of "1," as well as a series of other small sizes that seem to correspond to scaling factors that don't exist in the info.json response. The problem is that long or tall images (0.5 < aspect ratio < 2) requested with one dimension fixed at 1 pixel causes IIIF image servers to compute a rounded dimension of 0 pixels for the other dimension. That results in the IIIF server PROPERLY (according to IIIF specs and tech slack channel) returning a 400 Bad Request response in HTML format rather than an image - yet Mirador is assuming an image is returned. When Mirador 2.x encounters the error, the image is not properly rendered until the user zooms or pans in the slot. The workaround was to ensure that our IIIF server never rounds below 1 px in the size computation although this is discouraged by the specifications so I think Mirador should be fixed or the Mirador community make a case for altering the IIIF specs to accommodate this condition. Mathematically speaking, one could argue that a source image that is 3000x1000 is closer to the actual aspect ratio of 3:1 when resized to a 1x1 image than a 1x0 image's aspect ratio which is undefined / non-existent.

• ```

[beaudet]

Note that the screenshot above shows the FIXED behavior. I didn't capture screenshots of the broken behavior, but instead of the map displaying in the slot, a small white square about 10x10 pixels is rendered instead of the image - this is purely browser / Mirador behavior as the unpatched IIP server returns HTML and a 400 Bad Request response rather than an actual image.

[cbeer]

I've moved this issue over to our "new" repository for Mirador 2. Unfortunately, Mirador 2 is no longer well supported by the community and most of our efforts are on improving Mirador 3.

I can't tell from your report, but might this be an issue to pursue with OpenSeadragon (if they haven't already fixed it) or in the IIIF community.

[beaudet]

Yeah, I figured that was probably the case. I'll try the manifest with Mirador 3 and see if it has similar behavior... or maybe someone already knows?

[beaudet]

As far as I can tell using the demo M3, M3 doesn't request image sizes smaller than the smallest scale factor, e.g. "1,", "2,", "4,", "8,", etc. as M2 seems to do, so I don't think there's anything to fix in M3.

[cbeer]

👍 ; openseadragon must have fixed something. I don't know what it'd take to update OSD here.