IIIF Presentation 3 not supported

[keewerner]

All the examples at https://mirador-download-plugin.netlify.app/ use IIIF presentation level 2 examples. Manifests using IIIF level 3 instead don't work - the plugin loads but no actual page gets shown.

[massimozallocco]

I'm experiencing the same problem. Manifests IIIF level 3 not supported. The rendered link to images looks like "/full/640,/0/default.jpg?download=true" (missing image url).
Did anybody patched the error?
Thank you

[jeremy-liss]

I think this is the problem for us too. The download links point to a thumbnail URL, clicking on them opens a blank page. Has anyone managed to get it working with IIIF 3?

[keewerner]

There is a mirador-*s**hare* plugin which should allow to do the same as the (now defunct) download plugin: https://github.com/ProjectMirador/mirador-share-plugin Maybe that's the way to go ...

On 3/1/23 03:15, jeremy-liss wrote: I think this is the problem for us too. The download links point to a thumbnail URL, clicking on them opens a blank page. Has anyone managed to get it working with IIIF 3? — Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJUGUS5YOBSVMBSKEN2TPLWZ2WK3ANCNFSM5PJZRAPQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

-- /Nur wer es weiß: es nahen andre Zeiten Und schaffen uns noch rätselhafte Wesen /

[jeremy-liss]

Thanks for your help, I will investigate the share plugin.

[keewerner]

Let me know how it works out - the plugin is on my to-do list ...CheersSent from my phone

[jeremy-liss]

We have come across this plugin, it looks promising https://github.com/dbmdz/mirador-downloaddialog

[lutzhelm]

My guess is that this is a IIIF Image API 3 issue rather than a Presentation API problem. IIIF Image API does not support full size that is used in the code sample below, for example. I'll double check the image URI generation in all places, but it would be very welcome if any participants in this issue could provide any real world examples.

mirador-dl-plugin/src/CanvasDownloadLinks.js

Lines 39 to 44 in 85774ae

	const boundsUrl = canvas
	.getCanonicalImageUri()
	.replace(
	/\/full\/.*\/0\//,
	`/${bounds.x},${bounds.y},${bounds.width},${bounds.height}/full/0/`,
	);

[lutzhelm]

There are some issues with manifesto's Canvas.getCanonicalImageUri method, e.g.

• it does not provide canonical size parameters for IIIF Image API 3 in the first place (which are w,h instead of version 2's w,)
• it relies on version 2 full size parameter that is not supported in version 3
• it only provides a single image URI although there might be multiple images annotations or a Choice of images

Some of those issues might be fixable in manifesto, but a single image annotating the entire Canvas is only one (albeit extremely common) case, so it might be worth thinking about implementing the URI generation without manifesto.

@keewerner, @massimozallocco, @jeremy-liss: Sorry for the delay. I guess you all have found different solutions in the meantime, but could you still provide manifests where the plugin generated dysfunctional URIs? It would be very helpful to see if there are issues that I haven't identified yet.

[jeremy-liss]

@lutzhelm - it looks like this is working for our manifests now. I know that our manifests were updated at some point while we were working on rolling out Mirador, so I can't be certain whether it was updates to the plugin or manifest that fixed it

https://ndhadeliver.natlib.govt.nz/delivery/iiif/presentation/3/IE18987210/manifest