needs upgrade to new Zenodo api?

[abubelinha]

Sorry. A newbie question since I am basically trying to understand how IIIF manifests work.

I look at your linked static example manifest and compare to your php-generated manifest for Zenodo record #3758523:
Maybe your script is not generating the correct links anymore? since I don't see any references to 3758523 inside the generated json file.

Anyway, I am not sure whether I need to use one script like this for what I want to do. Perhaps you can give me advice on this:

I just want to use a lightweight IIIF viewer for single images stored in Zenodo, as we discussed in zenodo #1935 a while ago.
I see you have made a lot of research on this, and I hope in your experiments you have tried iipmooviewer-zenodo combination since that's exactly what I want (so I can keep using that viewer but point to images stored somewhere else).

But I am probably misunderstanding how IIIF clients work.

1. I thought the manifest was responsability of the image server itself (Zenodo), so I could point a client viewer directly to a Zenodo-generated IIIF endpoint like this for your example:
   https://zenodo.org/api/iiif/record:3758523:Satdhara%20stupa.tif/info.json

2. Now I also see that Zenodo json record api answer includes links to what they call self_iiif_manifest:
   "self_iiif_manifest": "https://zenodo.org/api/iiif/record:3758523/manifest"
   Does this mean a php script like yours is not needed anymore?

Which kind of url do I need to point iipmooviewer to, so I can run just the client in my server (i.e. github page) and let users navigate a Zenodo-stored image? I am not being able to do that (see iipmooviewer #80).
What am I missing?

Thanks a lot in advance for any advice you can provide.
@abubelinha

[jpadfield]

Hi, this project was an experiment demo rather than a long term solution and I have not had a chance to update it in relation to the recent changes at Zenodo and the underlying Invenio RDM software.

The info.json files are normally generated by the IIIF server automatically. but this does not always be the case, particularly if there are CORS issues one could make them, but this is not ideal.

Now the manifest is an other thing - anyone can generate these based on the information in the relevant info.json files. But ideally a base manifest would also be generated by the system hosting the IIIF service.

This code basically scraped information from the Zenodo site, including the relevant info.json files and automatically created a IIIF manifest that could then be loaded into any IIIF viewer - subject to Zenodos then tile limit.

However, as the Zenodo system has been updated the scraping process will be broken and I will have to find some time to update it ... :-) Ideally Zendo might publish its own manifests but this may well be a ways off.

[jpadfield]

I have now updated the code for the new API, but there seems to be an issue with the Zenodo info.json files not returning height and width so I can not get the manifests to correctly resolve at the moment.

There is a link to a IIIF manifest provided in the Zenodo API output, but this also is not formatted correctly and will not display in a IIIF viewer ... at this time ...

[abubelinha]

@jpadfield, thanks a lot for taking a look at this

there seems to be an issue with the Zenodo info.json files not returning height and width so I can not get the manifests to correctly resolve at the moment.

From your explanations I guess a workaround would be storing width and height myself when I upload files, plus file name and Zenodo record number. Should them be enough to generate correct manifests myself for now? (until this is solved and I don't need to keep that info client-side).

If you agree, I would report this into a new Zenodo issue (but please do it yourself if you wish: I am so interested in this being solved but you can explain it much better than me):

• Previous Zenodo version was correctly including height and width in the returned info.json (so you could read them with PHP when you created this repository). But after Zenodo api changes you can't do it anymore.
• Also, this explains iipmooviewer#80, which is not iipmooviewer-client's fault but zenodo-api-server's fault (do you agree on this?)

Do you keep any example of an old-Zenodo-api info.json file, for comparison?
I understand this is not an InvenioRDM IIIF issue, since in zenodo#1935 you provided a InvenioRDM-IIIF-served image which is correctly showing width and height in the returned info.json.

BTW I'll tried to adapt my failed iipmooviewer-Zenodo test and point to your image instead (just to confirm that client can correctly connect a remote IIIF server, in order to close iipmooviewer#80).
But it CORS-failed:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Access to XMLHttpRequest at 'https://tudor-portraits.npg.hasdai.org/api/iiif/v2/sr6vd-hwv66:6768_2008_IRR_mosaic01_adjusted.tif/info.json' from origin 'http://localhost:81' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Does that mean your IIIF-server does not allow cross-domain requests? Can I overcome that like you said here?:

The info.json files are normally generated by the IIIF server automatically. but this does not always be the case, particularly if there are CORS issues one could make them, but this is not ideal.

I don't quite understood that comment. Do you suggest to avoid CORS problem by provinding my IIIF-client a info.json copy stored in my same server (but pointing to a tiff in your remote IIIF server), and that would be enough to trick the browser?

Thanks again
@abubelinha

[jpadfield]

You would need to do more than store the width and height - basically some kind of proxy option in relation the IIIF server, this will probably be a bit complex.

As far a reporting things to Zenodo please do go ahead as I do not have the time to chase this at the moment :-(

However, please note that it might not be a bug, it may just be that the functionality has not been implemented yet - so it is good to check what you should be able todo :-)

The spec for a info.json file is described at: https://iiif.io/api/image/3.0/#52-technical-properties, but you can se a simple example at: https://iiif.bodleian.ox.ac.uk/iiif/image/e58b8c60-005c-4c41-a22f-07d49cb25ede/info.json

It may be related to InvenioRDM as the tudor system is an older version so things will have changed. Or it may be related to how Zenodo uses it.

CORS is an issue - the tudor system was setup as a project demo rather than a reuse platform so CORS may not have been setup by the developers ....

CORS is a security issue when javascript asks for external files - if the system serving the files do not offer the right headers then you get the CORS error. However, though not recommended as it breaks very easily, it would be possible to setup something on another server which acts as a proxy for the json files and re-serves them with the correct headers - but this is not a great idea and it is better for the correct CORS headers to be added at source ... if that is possible.

[abubelinha]

Thanks for long explanations. So we'd better write to Zenodo support and ask about this.
Even if not a "bug", I understand this is a "step back" in the info provided by Zenodo server IIIF info.json files.

My only clue for saying this is your php code repository (which I didn't test).

$h = $arr["info"]["height"];
$w = $arr["info"]["width"];

If those lines worked in the past, it means Zenodo was providing width and height in returned info.json (>3 years ago) ... and now stopped to provide them in its most recent api version.

[jpadfield]

Certain bits of information, like height and width, are required for IIIF to work, if their info.json files do not include then something odd has happened.

If they are using a standard IIIF server it should just work, but I expect they have something more complex, probably relating to their security settings.

So yes the simple situation is that the info.json files they produce do not seem to be following the standard and their IIIF manifests also do not seem to be formatted correctly or list the relevant images ...