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

feature suggestion: per image MAX_LAYERS #246

Open
zabak opened this issue Nov 20, 2022 · 11 comments
Open

feature suggestion: per image MAX_LAYERS #246

zabak opened this issue Nov 20, 2022 · 11 comments

Comments

@zabak
Copy link

zabak commented Nov 20, 2022

Similar to #245 I have a use case for dynamically changing the MAX_LAYERS parameter per image. Most of our jpeg2000 images have 12 quality layers and it is OK to read just several of them - some of them are maps compressed losslessly so need to avoid reading all quality layers. On the other hand, in some cases we have too high lossy compression (1:30) and we need to read all quality layers to display a good image. We could use a proxy to add the correct number of layers to the request.

@ruven
Copy link
Owner

ruven commented Nov 20, 2022

But how would the server know how many layers to decode for a particular image?

Don't forget, there's the existing LYR parameter. Doesn't this do what you need? For each image request, you can specify the number of quality layers to decode. For example: FIF=image.jp2&LYR=12&WID=500&CVT=jpeg will decode all 12 quality layers to create an image 500px in width.

@zabak
Copy link
Author

zabak commented Nov 20, 2022

We would have to update the metadata to let the server know. The parameter above does not work with IIIF requests which we solely use to get images from the imageserver nowadays.

@ruven
Copy link
Owner

ruven commented Nov 21, 2022

We would have to update the metadata to let the server know.

So, this would be a fixed value in the JPEG2000 metadata? That's certainly possible, but the problem is that it will be limited to Kakadu as OpenJPEG currently cannot handle this kind of metadata.

@zabak
Copy link
Author

zabak commented Nov 21, 2022

Not the metadata embedded in the image. I guess we would have to update some external metadata, perhaps whatever we have in Solr. The proxy is asking for some metadata anyway, because of access rights, so there would be one more field to check. And another field for the watermarks, perhaps.

@ruven
Copy link
Owner

ruven commented Nov 21, 2022

If it's not in the image metadata, how would you let iipsrv know how many layers to decode?

@zabak
Copy link
Author

zabak commented Nov 21, 2022

Because of the intermediate proxy, that checks for access rights. Users do not communicate with the imageserver directly, they go to the proxy.

@zabak zabak closed this as completed Nov 21, 2022
@zabak zabak reopened this Nov 21, 2022
@ruven
Copy link
Owner

ruven commented Nov 24, 2022

OK, but how would the proxy let the image server know the number of layers to decode in that case?

@zabak
Copy link
Author

zabak commented Nov 24, 2022

I will just keep the number of layers in Solr index, probably just for the cases where I need something different from the default.

@nicolasfranck
Copy link
Contributor

Depends on what you're using from the iipsrv. If you are using the IIIF then you are limited to the parameters that the IIIF image api standard uses (so no layers). Or you may use the FIF directly, in which case you can use that LYR parameter. Anyway, that IIIF internally uses the FIF in some way (right @ruven ?), but you will have reimplement the mapping between the standards yourself.

@zabak
Copy link
Author

zabak commented Jan 24, 2023

@nicolasfranck I am using IIIF and that is why I am looking for a solution with the proxy - I know the number of layers I want to provide for each image (and it might vary).

@ruven
Copy link
Owner

ruven commented Jan 24, 2023

Anyway, that IIIF internally uses the FIF in some way

Yes, each IIIF request is directly mappable to an IIP request, so a solution would be to rewrite the requests to FIF= format and add the LYR parameter to it.

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