-
Notifications
You must be signed in to change notification settings - Fork 3
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
How to show a default crop with max-width:100%? #14
Comments
Thank you for opening this issue, @D-Groenewegen! I'm not completely sure, if I understand what causes your problem. Could you please share the manifest url you used, so that I can try it out on my own? Update: |
Thanks for your lightning reply! The URL for the crop: https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x00001d/pct:34.70437,13.53108,35.37275,75.99858/pct:100/90/default.jpg Manifest for the full manuscript from the British Library: https://api.bl.uk/metadata/iiif/ark:/81055/vdc_100123802477.0x000001/manifest.json Example of an image in html: As for the presentation API, one of my other test cases is https://damsssl.llgc.org.uk/iiif/2.0/4623419/manifest.json (National Library of Wales). When loading Mirador with this manifest, I noticed that the ImageCropper menu icon appeared only for a nanosecond before it disappeared. (There is also https://damsssl.llgc.org.uk/iiif/3.0/4623419/manifest.json but it might be active as a redirect only) |
Thank you for your answer and the manifest urls! I think the is a bug in the implementation of the Image API provided by the british library, when Did you open the manifest from Wales in single or in book view? |
Thanks, I was too hasty in assuming that a difference in API versions had anything to do with the issue I had with NLW's manifests. In fact, the manifest URL from BL above also links to https://iiif.io/api/presentation/2/context.json and http://iiif.io/api/image/2/context.json. I opened the manifest in book view and hadn't yet tried switching to single view. But that seems to work! (The BL manifest doesn't support book view anyway.) I'll check if the issue reported here applies to manifests from other libraries. |
At the moment, the plugin does only work in single view. |
I've learnt that the British Library are in the progress of upgrading their implementation and are now aware of the issue.
Another example of an IIIF collection where the crop did not correspond to what I selected is from this manifest (BnF): Could it be that the absolute image size could not be retrieved so that percentages lack orientation? |
Thanks for this other manifest, what kind of issues do you see with it? I tried some pages with differente region, looks all good 🤔 |
The build I'm testing can be viewed here: https://www.vanhamel.nl/codecs/Show:IIIF/September2021 In this screenshot I've tried to show the actual selection and the preview side by side: P.S. I experienced some difficulties using the tool after having zoomed in on the image, but that's for a separate issue. |
I guess, this is again an issue with the API 🤔 the plugin just takes, what it gets from the manifest and the |
Oh dear! Would you be able to spot what's missing from, or what's improperly configured in, those manifests that's causing these issues? Or should we be looking for causes elsewhere? |
Hi Matthias, I inquired on the IIIF Slack channel and got some response which I hope will be helpful to you. From https://github.com/dbmdz/mirador-imagecropper/blob/main/src/components/CroppingDialog.js#L111 it appears that the tool takes the
What you also need on top of that is the absolute size of the pixels. In the case of the British Library at least, you need to take the I hope that makes sense! *Note to self (for my own sanity): these files are not explicitly linked from the manifest but follow a naming convention: see https://iiif.io/api/image/3.0/#21-image-request-uri-syntax. For instance, the info.json associated with https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/full/max/0/default.jpg is https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/info.json |
In the example https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/info.json the image is 6016 pixels wide but I think @D-Groenewegen 's original problem comes from the use of the size value I guess the plugin should read the |
using This is because the processing order is clearly defined in the spec: https://iiif.io/api/image/3.0/#46-order-of-implementation (Region THEN Size...) However there does appear to be a difference when using the cannonical |
You are right @irv the BL's image server has the same (wrong) behavior for The order of region and size operations is relevant in so far as the The BL server's behavior is wrong because it returns an image with an invalid area when the resulting size is above
It also returns the same wrong area for
|
Many thanks for making this plugin available! If I understand correctly, it is the Mirador 3 successor to https://github.com/dbmdz/mirador-plugins/tree/main/ImageCropper (to judge by the installation instructions requiring webpack) and probably doesn't work with IIIF Presentation API lower than 3.0 (my test cases with 2.0 didn't work).
When I tried it out, I noticed that selected regions are based on percentages (per https://iiif.io/api/image/3.0/#41-region). That is wonderful because it is the only way to retrieve the region irrespective of image size. However, the image size is set at the maximum
pct:100
by default and when I copy the URL and want to show an image with a max-width of 100%, the region becomes distorted and what remains gets a dark background, as demonstrated in this image:The image at the bottom is the actual region, with image size set to
500,
. The one at the top shows what goes wrong when it is set topct:100
.I've googled for solutions but couldn't find any (yet). Could anyone a recommend how to deal with this issue?
The text was updated successfully, but these errors were encountered: