Image Display for e-rara Content in Version 4.1.0

[rawliq]

UV version:

 universalviewer@4.1.0

I'm submitting a:

• bug report => please fork one of these codesandbox examples with a repro of your issue and include a link to it below
• feature request => please use the user stories repo
• support request => Please do not submit support requests here, use stackoverflow

Current behavior:

Images embedded via IIIF manifests from e-rara are cropped in v4.1.0:
https://www.universalviewer.dev/#?xywh=-1434%2C-283%2C5636%2C4188&iiifManifestId=https%3A%2F%2Fwww.e-rara.ch%2Fi3f%2Fv20%2F30339522%2Fmanifest

Is this a bug or an issue with our IIIF manifests/images?

Expected behavior:

For comparison v4.0.0:
https://uv-v4.netlify.app/#?manifest=https://www.e-rara.ch/i3f/v20/30339522/manifest&c=&m=&cv=&xywh=62%2C440%2C2709%2C2013

Steps to reproduce:

Related code:

// insert any relevant code here

Other information:

[demiankatz]

I suspect this is somehow related to OpenSeadragon, since we upgraded to a newer version of OSD in 4.1.0 (upgrading from 2.4.2 to 4.1.1). It may be worth investigating OSD changelogs to see if that might point us toward a solution.

I'm not sure if a clean downgrade is possible, but it might be worth experimenting with reverting to 2.4.2 in package.json and rebuilding the viewer, to see if that solves the problem. Obviously, that's not a long-term solution at the project level, but it might be a good local workaround in the shorter term.

For others who are investigating this, here's a direct link to the manifest for convenience: https://www.e-rara.ch/i3f/v20/30339522/manifest

@rawliq, can you tell us what image server (or tile generator) you are using, in case that is also a factor here?

[rawliq]

@demiankatz, our service provider is using a custom solution and not a specific product.

[demiankatz]

@rawliq, you may want to talk to your service provider about this problem. I just tested the same manifest in the Mirador viewer, and it displays the same problematic behavior there. Thus, the problem is not specific to the Universal Viewer (which probably means it has something to do with lower-level behavior in OpenSeadragon, as I previously speculated). I think it will have to be fixed either at the service provider level (if they're doing something non-standards-compliant that can be corrected) or at the OSD level (if it's a bug in that rendering layer).

Please let me know if I can be of further assistance, but since the problem is not directly related to UV, I don't think there's more we can do on this side (apart from updating to a newer version of OSD, if the problem gets fixed there).

[rawliq]

@demiankatz, yes, we are in contact with them. Thanks for the feedback and the note on the Mirador viewer!

[demiankatz]

@rawliq, I did a bit more digging and found that whatever this problem is, it was introduced by OpenSeadragon 4.1. I have opened #1339 to downgrade us to OpenSeadragon 4.0 until a solution can be found; that should make your manifests functional again.

This is only a theory, and I haven't done any work to confirm it yet, but I strongly suspect that this PR may be a factor in the problem: openseadragon/openseadragon#2337 -- OSD 4.1 changes the way the "sizes" information in info.json is used, which sounds like a significant change in tile selection. This could mean that there's a bug in OSD, or that OSD is simply more sensitive to imperfectly-formed IIIF image metadata.

[demiankatz]

I've raised this issue on the OSD GitHub: openseadragon/openseadragon#2691 -- let's see if that starts a helpful discussion to get us past this hurdle.

[rawliq]

Thanks a lot, @demiankatz !

[rawliq]

Our technical team has now added more tiles/scale factors. Until now, we had only provided this tiling information for oversized material (such as maps): https://erara.dev.vls.io/i3f/v20/8923977/info.json.

This resolves our problem for now.