openseadragon: When loading some IIIF tilesets, incorrect URL's are being fetched for certain tiles
I’m trying to build an OSD canvas that takes images from multiple groups of IIIF tilesets, each with their own info.json and source images. These are then stacked, one on top of each other, sequentially down the canvas. This has been implemented fine and can create a canvas that works great for the most part.
When trying to use an IIIF source to load some of these “rows” into OSD, there are occasional errors with OSD fetching tiles that include the wrong URL. This doesn’t happen with every single group of IIIF tilesets, but for the ones where it does happen, it is a consistent reproducible error.
Examples:
URL that OSD generates to get a particular tile:
my-server.com/my-images/image_001/8192,0,1836,604/57,/0/default.jpg
info.json:
{
"@context": "http://iiif.io/api/image/2/context.json",
"@id": "https://my-server.com/my-images/image_001",
"profile": [
"http://iiif.io/api/image/2/level0.json",
{
"formats": [
"jpg"
],
"qualities": [
"default"
]
}
],
"protocol": "http://iiif.io/api/image",
"tiles": [
{
"scaleFactors": [
1,
2,
4,
8,
16,
32
],
"width": 256
}
],
"width": 10028,
"height": 604
}
URL:
my-server.com/my-images/image_002/8192,0,1765,601/55,/0/default.jpg
info.json:
{
"@context": "http://iiif.io/api/image/2/context.json",
"@id": "https://my-server.com/my-images/image_002",
"profile": [
"http://iiif.io/api/image/2/level0.json",
{
"formats": [
"jpg"
],
"qualities": [
"default"
]
}
],
"protocol": "http://iiif.io/api/image",
"tiles": [
{
"scaleFactors": [
1,
2,
4,
8,
16,
32
],
"width": 256
}
],
"width": 9957,
"height": 601
}
The actual location of the image on the server:
my-server.com/my-images/image_001/8192,0,1836,604/58,/0/default.jpg
my-server.com/my-images/image_002/8192,0,1765,601/56,/0/default.jpg
…
Patterns that I’ve recognized are
- it’s always happening with tiles that are scaled from the right hand side of the root image - I.E there are never bad fetches from the start or middle of an IIIF tileset
- it’s always OSD that queries the
size.wparam as one less than what’s actually provided by the server - E.G.../8192,0,1836,604/57,/..., instead of.../8192,0,1836,604/58,/...
These tiles that fail to load tend to only become visually apparent when zoomed out in the OSD canvas - for some reason, when zooming in, OSD can generate the URL’s for the higher resolution tiles just fine. Im not sure if this is consistent, but for all the example images I’m using in my project, this has been the case.
You’ll notice that the height and width properties for each source image are different between the two groups - each group that I’m trying to build has a slightly different dimensions, but naively I would assume that as long as OSD adheres to the IIIF spec, it shouldn’t matter.
Considerations:
- I have tried using two different libraries to generate these IIIF tilesets (https://github.com/lovell/sharp + https://github.com/glenrobson/iiif-tiler), and both of these create identical IIIF tilesets - I do not believe the source image mapping is the problem, but rather OSD since that’s the common denominator.
- I have generated tilesets with multiple
sizeparameters (128, 256, 512, 1024) - while the generated tilesets will be different, there will still typically be a few of these issues when OSD tries to load any of them, and it will still always be the end tiles.
I have a gut feeling that this seems to be some sort of Math.round() error, since the problematic tiles are always off by 1. Perhaps the IIIF implementation in OSD is handling odd numbers weirdly when generating the URL from the size/scale factor params in the info.json? If that’s the case, it would be good to try and fix it - would like to try and plug all these holes in my OSD canvas 😄
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 2
- Comments: 34 (28 by maintainers)
FWIW, when I asked in the IIIF’s Slack about #2206 originally, there was this comment:
I’m going to mention this new issue there and see if anyone has anything to say.