Support level 0 IIIF images

[jsbien]

This would allow to view images posted at GitHub Pages, such as
https://jsbien.github.io/Parkosz4IIIF/collection/ParkoszJBC/index.json
https://jsbien.github.io/Parkosz4IIIF/collection/ParkoszMF/index.json
https://jsbien.github.io/Parkosz4IIIF/collection/ParkoszPWN/index.json

This actually is a specific case of the still open issue #520.

[DiegoPino]

Hi,

seconding question/need for this and #520. But also the need for simply no service definition at all under a given ImageResource

Should i open a new issue to target beta3 or adding here is good enough?

Looking at the code in Beta3 i see that fetchInfoResponse is always called.

https://github.com/ProjectMirador/mirador/blob/v3.0.0-beta.6/src/components/WindowViewer.js#L38

mirador/src/state/actions/infoResponse.js

Line 70 in e739c84

export function fetchInfoResponse({ imageId, imageResource }) {

leading to this error in case of an absent service definition in a
IIIF Manifest version 2.1

TypeError: undefined is not an object (evaluating 'e.getImages()[0].getResource().getServices()[0].id')

At least for version 2.1 the specs, the way i read them (can be wrong) imply that service is only needed if exists. From the specs at https://iiif.io/api/presentation/2.1/#image-resources

If a IIIF Image API service is available for the image, then a link to the service’s base URI should be included. The base URI is the URI up to the identifier, but not including the trailing slash character or any of the subsequent parameters. A reference to the Image API context document must be included and the conformance level profile of the service should be included. Additional fields from the Image Information document may be included in this JSON object to avoid requiring it to be downloaded separately. See the annex on using external services for more information.

Our use case for this is related to static served images as everyone elses, but also to one edge case
if the above specs v/s implementation definition.

Given an Image Resource with a given @id, lets say this json snippet

"resource":{ "@id": "http://localhost:8183/iiif/2/81e%2Fapplication-multi-size2-cff793b4-058d-4729-8d4d-befdd000969f.pdf/full/full/0/default.jpg?page=2

See the added GET argument of page=2. We want to use Cantaloupe's Page PDF extraction capabilities. That @id is correct and returns second page of a PDF. Without the Service, Mirador 3 fails to display/access the Image, if we add service, the specs kick in, replacing the call?/recreating the call? (that is what i'm not sure of, maybe the info.json is just accessed to fetch sizes?) but since the info.json URI is constructed without using the arguments of the @id, not the Image resource ones or if we add one to the Service ID, we end with always the same image, for page 1 to N.

We fixed this on the IABookreader implementation by getting arguments and moving them after the info.json, but also by allowing non service exposed images to be served. Is this something else could need?

Thanks a lot

[mejackreed]

Thanks both @jsbien and @DiegoPino for raising this. #2976 aims to fix this for Presentation v2, and you can test if it works for you here: https://deploy-preview-2976--mirador-dev.netlify.app/__tests__/integration/mirador/

[jsbien]

On Thu, Apr 16 2020 at 16:27 -07, Jack Reed wrote: Thanks both @jsbien and @DiegoPino for raising this. #2976 aims to fix this for Presentation v2, and you can test if it works for you here: https://deploy-preview-2976--mirador-dev.netlify.app/__tests__/integration/mirador/

I've added my resource https://jsbien.github.io/Parkosz4IIIF/collection/ParkoszJBC/index.json which was accepted but only the metadata are displayed. Am I doing something wrong or there is still a problem in Mirador? Best regards Janusz

…

-- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien

[mejackreed]

@jsbien Thanks for the quick reply. I think the initial implementation only supports IIIF Presentation v2. I think if you converted to v2 things should work, or we could also look at adding v3 support.

[jsbien]

On Fri, Apr 17 2020 at 6:28 -07, Jack Reed wrote: @jsbien Thanks for the quick reply. I think the initial implementation only supports IIIF Presentation v2. I think if you converted to v2 things should work, or we could also look at adding v3 support.

I'm sorry but I just use https://github.com/UniversalViewer/uv-app-starter without fully understanding how it works. Moreover my only goal is to display https://jsbien.github.io/Parkosz4IIIF/ in Mirador to allow to compare the versions easily. Please be more explicit in your suggestions. Should I request a modification of uv-app-starter?

[DiegoPino]

@mejackreed this is great! Thank you so much 👏 =)

Looking at the committed code i deduce it will work on V2 manifest only, right? Not an issue, just want to be sure. We can deal with both so pretty happy!!

Which is the next published Tag/Beta that will get this commit? To update our library dependencies.

Cheers and thanks again, great work

[mejackreed]

An update to @jsbien and @DiegoPino , I'm working on supporting Presentation v3 and so will hopefully have a pull request in shortly.

@DiegoPino this will get released in v3.0.0-beta.7 and that should get released as soon as the lingering table of contents and others get reviewed. Hopefully soon.

[mejackreed]

Also @jsbien I found another issue with the manifests you created which you may want to request modification to uv-app-starter. The canvases do not have height and width properties which they must have.