How to show a default crop with max-width:100%?

[D-Groenewegen]

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 to pct:100.

I've googled for solutions but couldn't find any (yet). Could anyone a recommend how to deal with this issue?

[morpheus-87]

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:
I was mainly using both Presentation and Image API in version 2.1.

[D-Groenewegen]

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:
<img id="imgApiTarget6" style="max-width:100%; height:auto;" data-info="https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x00001d" src="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">

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)

[morpheus-87]

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 500, for size works well (full also breaks the image). Do you know what IIIF server they are using?

Did you open the manifest from Wales in single or in book view?

[D-Groenewegen]

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.

[morpheus-87]

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.)

At the moment, the plugin does only work in single view.

[D-Groenewegen]

I've learnt that the British Library are in the progress of upgrading their implementation and are now aware of the issue.

I'll check if the issue reported here applies to manifests from other libraries.

Another example of an IIIF collection where the crop did not correspond to what I selected is from this manifest (BnF):
https://gallica.bnf.fr/iiif/ark:/12148/btv1b100378503/manifest.json

Could it be that the absolute image size could not be retrieved so that percentages lack orientation?

[morpheus-87]

Another example of an IIIF collection where the crop did not correspond to what I selected is from this manifest (BnF):
https://gallica.bnf.fr/iiif/ark:/12148/btv1b100378503/manifest.json

Thanks for this other manifest, what kind of issues do you see with it? I tried some pages with differente region, looks all good 🤔

[D-Groenewegen]

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.

[morpheus-87]

I guess, this is again an issue with the API 🤔 the plugin just takes, what it gets from the manifest and the info.json.

[D-Groenewegen]

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?

[D-Groenewegen]

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 width and height of the canvas from the manifest, like you said yourself. However, these values do not represent absolute units, but they are intended to set the aspect ratio - see https://iiif.io/api/presentation/3.0/#width:

width : The width of the Canvas or external content resource. For content resources, the value is in pixels. For Canvases, the value does not have a unit. In combination with the height, it conveys an aspect ratio for the space in which content resources are located.

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 maxWidth and maxHeight from the info.json of each canvas.*

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

[robcast]

maxWidth and maxHeight are limits for the maximum pixel size you can get out of the image API (https://iiif.io/api/image/2.1/#profile-description). The size value max automatically limits the resulting image to this size, regardless of its original size.

In the example https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/info.json the image is 6016 pixels wide but maxWidth is 2000. This means that you can not request the full width of the image at full resolution. You can request the image at a lower resolution (which is what the max width URL does, which effectively restricts the image to 2000px) or request multiple smaller tiles at full resolution (which is what Mirador usually does when you zoom in).

I think @D-Groenewegen 's original problem comes from the use of the size value pct:100 with an image that has a limited maxWidth: When you specify an area that contains the full width of the image and pct:100 then the resulting image would have to be wider that maxWidth. I think the server should return an error in this case but it seems that the BL server returns a wrong portion of the image instead.

I guess the plugin should read the maxWidth of the image API and disable the pct:100 size or use max instead.

[irv]

using max or pct:100 in the size parameter results in exactly the same behaviour. If you request full/maxor full/pct:100 you get an image that's 1422x2000. e.g. https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/full/max/0/default.jpg and https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/full/pct:100/0/default.jpg

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 w, size as stated

[robcast]

You are right @irv the BL's image server has the same (wrong) behavior for max and pct:100 so it wouldn't help to use max instead. To create a valid image API URL the client has to calculate the maximum valid size using maxWidth and maxHeight of the image service.

The order of region and size operations is relevant in so far as the pct: size is defined as "percent of the width and height of the extracted region" (I had to look this up again ;-) which makes it slightly more complicated to calculate the maximum value before the maximum size is crossed.

The BL server's behavior is wrong because it returns an image with an invalid area when the resulting size is above maxWidth and it should return an error:

• ok: https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/pct:10,70,70,10/1000,/0/default.jpg
• ok: https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/pct:10,70,70,10/pct:30/0/default.jpg
• invalid request, wrong area: https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/pct:10,70,70,10/3000,/0/default.jpg
• invalid request, wrong area: https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/pct:10,70,70,10/pct:100/0/default.jpg

It also returns the same wrong area for max which should be a valid size:

• valid request, wrong area: https://api.bl.uk/image/iiif/ark:/81055/vdc_100123803593.0x000049/pct:10,70,70,10/max/0/default.jpg