Static `thumbnail` ignored when image isn't static

I am the author or maintainer of this manifest: Yes
URL: See #3312
Manifest hosting institution will be GitHub

Observed behavior

Description: Thumbnails aren't used

This is a follow up of #3312, since this finding a workaround for this feature request led to the issue described here.

The current Mirador 3 ignores thumbnail sections under certain circumstances. I did a quick analysis and found a possible cause:

In

mirador/src/lib/ThumbnailFactory.js

Line 191 in 1415d2e

if (thumb && iiifImageService(thumb)) return this.iiifThumbnailUrl(thumb);

there is a check if resource.getThumbnail() from line 190 has returned something and if this the method iiifImageService returns something (which it couldn't since we aren't providing a service section for the thumbnail). This evaluates to false. Then line 193 is triggered which just returns undefined - this is almost certainly wrong and probably causes the following code to construct the bogus requests described in #3312. I can actually understand the reasoning behind this, but such "magic" should be documented well and configurable, since it's violating the expectations implied by the IIIF spec.

Disabling line 193 fixes the problem, but the thumbnails are not very well aligned. It now just looks like bad design but not like a partly broken interface ;) I don't know what else this change breaks. I didn't dig deeper since these findings should be enough to patch out this line locally. BTW, a complete static example like https://iiif.manducus.net/manifests/exp/static.json doesn't cause this.

I've published some examples that provide resolvable image links:

By the way, these files won't display the thumbs in Universalviewer either, maybe it's a fault on my side. Can you please have a look?

Thank you for publishing these manifests, its most helpful in debugging this issue. One thing I noticed and was wondering based off the expectations of the mirador algorithm, on whether the image resources should have an @id that is resolvable to the static image resource.

"images":[{
                         "@context":"http://iiif.io/api/presentation/2/context.json",
                         "@id":"https://static.projektemacher.org/blaufusstoelpel/post/moden-zeitung-7-00/annotation/front",
                         "@type":"oa:Annotation",
                         "motivation":"sc:painting",
                         "resource":{
-                            "@id":"https://static.projektemacher.org/blaufusstoelpel/post/moden-zeitung-7-00/front",
+                            "@id":"https://static.projektemacher.org/blaufusstoelpel/post/moden-zeitung-7-00/front/full/full/0/default.jpg",
                            "@type":"dctypes:Image",
                            "format":"image/jpeg",
                            "service":{
                               "@context":"http://iiif.io/api/image/2/context.json",
                               "@id":"https://static.projektemacher.org/blaufusstoelpel/post/moden-zeitung-7-00/front",
                               "profile":"http://iiif.io/api/image/2/level0.json"
                            },
                            "height": 7193,
                            "width": 5322
                         },
                         "on":"https://xn--blaufusstlpel-qmb.de/post/moden-zeitung-7-00/canvas/front"
                    }]

Though I'm not seeing that file available. I'm not sure this is the "right" thing for Mirador to be doing but it seems like we are expecting that to be available to us. What do you think?

Well, I don't think that my thoughts matter in that issue, I'm not an IIIF expert, actually I didn't even read the according part of the specification.

I've created theses tiles (and the directory structure) with libvips, because it's the fastest generator that I could find (I've also tried iiif_static.py and go-iiif), see. If you want to try it yourself, make sure you get at least version 8.10.2.

I think that if it's not required by the specification, it shouldn't be required by Mirador.

I'm not exactly sure, but I read this:

https://iiif.io/api/presentation/2.1/#id

A content resource must have exactly one id unless it is embedded in the response, and it must be the http(s) URI at which the resource is published.

And would expect it to be there.

Yes, you're right. It's my understanding as well. But honestly I'm not seeing the relevance in this issue yet. This is about the thumbnail, unless the implementaion is mixing concerns here, it shouldn't matter that the id doesn't lead to a diplayable image...

Update 1
BTW, the missing image you noted is a known problem of LibVIPS, I'll try to fix it with my scripts for now.

Update 2
According to the spec it should be:

I suppose there is a very good reason for that and that they aren't just sacrificing backwards compatibility for cosmetic reasons.

Update 3
I've updated my manifest to include the full URL as Id to the full resolution image but it breaks Mirador since it tries to construct a manifest URL from it, like https://static.projektemacher.org/blaufusstoelpel/post/saison-4-87/front/full/full/0/default.jpg/info.json. I don't include the message from the browser console since the stack trace isn't of any value since line numbers and method names are from the minified source.

I guess this is a dead end investigating for this issue, but might be another one on it's own.

Just adding a note here that I think some of the static thumbnail requests might be resolved in #3394

@mejackreed: Yes, I can confirm that this works now as expected: See https://vorsatzpapier.projektemacher.org/post/1x1-des-tapezierens/
This is Mirador with static thumbnails. Many thanks, this issue can be closed now.