Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IIIF Image API #8

Open
thanneken opened this issue Jun 23, 2020 · 3 comments
Open

IIIF Image API #8

thanneken opened this issue Jun 23, 2020 · 3 comments

Comments

@thanneken
Copy link

I really appreciate many of the features in Relight. Among them is support for IIIF Image API as a tile source. It's not quite all the way there, though. I see "?IIIF=" in the viewer code, which makes me think it was developed on IIP in IIIF mode. The actual IIIF Image API uses only slashes as delimiters, so earlier IIP versions required a rewrite in the web server. The current IIP handles that internally.

I was able to get it to work by modifying two lines and adding two arguments in the HTML, as follows.

The first substitution is to replace:
t.metaDataURL = t.server + "?IIIF=" + t.path + "/" + t.img + "/info.json";
with:
t.metaDataURL = t.iiifServer + t.iiifPath + '/' + t.img + '.jp2/info.json';

The second substitution is to replace:
return t.server+?IIIF=${t.path}/${t.img}/${xr},${yr},${wr},${hr}/${ws},${hs}/0/default.jpg};
with:
return t.iiifServer + t.iiifPath + '/' + image + '.jp2/'+\${xr},${yr},${wr},${hr}/${ws},${hs}/0/default.jpg`;`

For general support the .jp2 should not be assumed since many repositories mask it. It could be in the iiifPath argument. There are many situations in which iiifServer and iiifPath could not be derived from variables already defined.

If you're curious how I'm using Relight, see: http://jubilees.stmarytx.edu/2020/relight.html

@sepastian
Copy link
Contributor

Thanks @thanneken!

I'm working on a PR implementing your suggesting.

For general support the .jp2 should not be assumed since many repositories mask it. It could be in the iiifPath argument. There are many situations in which iiifServer and iiifPath could not be derived from variables already defined.

Why are you using iiifServer and iiifPath instead of server and path? Could you give an example where deriving these is not possible, as you wrote?

Concerning masking of jp2: how about adding iiifExt?

@thanneken
Copy link
Author

A pull request sounds like a great idea. My head is not entirely in the code after all this time, but I would still think it good to allow the iiifServer to be defined. I believe there are repositories that dedicate a VM to the dynamic processing appropriate for the Image API and put static HTML on other servers. Would it be simple enough to define iiifServer as server if not otherwise defined?

Adding a variable for iiifExt sounds like a good idea, or perhaps identifierExt to follow the language of the Image API.

@ponchio
Copy link
Contributor

ponchio commented Mar 4, 2021

I think we can find a simpler solution.

Since the name of the RTI coefficient planes is fixed (plane_0, plane_1, plane_2), we need only the full path to the json file:

iiifPath: http://server.com/path/plane_0.jp2/info.json

the code should only take care to replace "plane_0" with "plane_1" and replace "/info.json" with the parameters of the file.

@ponchio ponchio closed this as completed Mar 4, 2021
@ponchio ponchio reopened this Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants