Extract region and OpenSeaDragon error

[swamidass]

Thanks for making this software available. I'm getting an error that might trace down to node-iiif, or perhaps something wrong in my url syntax. Basically, this url in a test iiif server we set setup (using serverless-iiif 4.0.2)

https://iiif.trustedkidney.com/iiif/3/test/test1.svs/full/512,/0/default.jpg

Leads to this error:

Error: extract_area: bad extract area

But iiif certainly can read this image. These link works just fine,

https://iiif.trustedkidney.com/iiif/3/test/test1.svs/full/1000,/0/default.jpg
https://iiif.trustedkidney.com/iiif/3/test/test1.svs/info.json

It isn't clear when a size specification will fail, and it seems that it is different for each image.

What is going on here, and is there a way to fix it?

[mbklein]

This looks a lot like what happens when the image extract/size calculation results in a rounding error. I've patched two of these in the past and thought I had them all squashed.

Does it still error out at values below 512? Can you try a few values between 512 and 1000 to see what the upper bound of the error is? What are the dimensions of your source image?

[swamidass]

These are the dimensions of the source image,

{"@context":"http://iiif.io/api/image/3/context.json","id":"https://iiif.trustedkidney.com/iiif/3/test/test1.svs","type":"ImageService3","protocol":"http://iiif.io/api/image","profile":"level2","width":12600,"height":21604,"sizes":[{"width":12600,"height":21604},{"width":6300,"height":10802},{"width":3150,"height":5401},{"width":1575,"height":2700},{"width":787,"height":1350},{"width":393,"height":675},{"width":196,"height":337},{"width":98,"height":168}],"tiles":[{"width":512,"height":512,"scaleFactors":[1,2,4,8,16,32,64,128]}],"extraFormats":["jpeg","tif","tiff","webp"],"extraQualities":["color","gray","bitonal"],"extraFeatures":["canonicalLinkHeader","mirroring","profileLinkHeader","rotationArbitrary","sizeByDistortedWh","sizeByForcedWh","sizeByWhListed","sizeUpscaling"]}

More information here too. Seems that regenerating the pyramid (not ideal) using vips resolves this problem, but creates another.

 vips tiffsave test1.svs test1.tiff --compression jpeg --Q 90 --pyramid --tile --tile-width 256 --tile-height 256

Now, this url (to the new tiff, not the svs) works fine:

https://iiif.trustedkidney.com/iiif/3/test/test1.tiff/full/512,/0/default.jpg

HOWEVER, Openseadragon is not able to correctly view this image, when directed to:

https://iiif.trustedkidney.com/iiif/3/test/test1.tiff/info.json

Did openseadragon stop working with iiif? or is their something about this version of iiif that breaks it?

[swamidass]

To your other question, currently the links are live, so you can test it yourself if you want. If it is a rounding issue, it will probably require a more careful scan than I'll do by typing stuff into the search bar, so that's why I made it available (for now) at a public link.

[swamidass]

And here is some more information, I verified that my OSD implementation works just fine on other people's IIIF servers (not sure their implementations). Seems that the errors in OSC are tracing back to image requests it's making on serverless-iiif. For example,

https://iiif.trustedkidney.com/iiif/3/test/test1.tiff/24576,32768,-11976,-11164/39,512/0/default.jpg

returns "Not Found." These sorts of errors are not appearing when I point to example IIIF (e.g. https://iiif.princeton.edu/loris/iiif/2/pudl0001%2F4609321%2Fs42%2F00000001.jp2/info.json). So it is making me think the root cause is some thing specific with serverless-iiif.

What are your thoughts? Is there a way to resolve this?

[mbklein]

https://iiif.trustedkidney.com/iiif/3/test/test1.tiff/24576,32768,-11976,-11164/39,512/0/default.jpg

I see a couple of issues here:

1. The width and height of the requested extract region are negative, which is not supported by the IIIF Image API
2. The x and y offsets of the requested extract region are larger than the dimensions of the image as reported by https://iiif.trustedkidney.com/iiif/3/test/test1.tiff/info.json.

When I adjust the extract region to be within the bounds of the image, I get a valid result.

After some experimentation with the first image, I've found that any request below 787 pixels wide triggers the error. I'll look at the calculator and see what I can find out.

[mbklein]

Looking more closely at the pyramid page dimensions:

  {
    "width": 787,
    "height": 1350
  },

It can't be a coincidence that the issue crops up right at one of the page boundaries, especially if regenerating the pyramid seems to resolve that part of the issue (which would rule out the rounding error I speculated about previously). Any request larger than 787 is going to use one of the larger frames and scale down, so it seems reasonable to suggest that the problem is with the data in pages 4 and 5. Regenerating the pyramid re-creates all 5 pages from the largest frame.

Is it possible that the initial pyramid is corrupted or truncated, or maybe didn't convert correctly the first time? If there's a way you can share the misbehaving pyramid TIFF file (test1.svs) with me, I might be able to see what's going on.

[mbklein]

I'm going to go ahead and close this since it's been a while. Feel free to reopen it or create a new issue if you still need assistance.

[swamidass]

I can share the misbehaving test1.svs with you here, but I'd rather not do so publicly. May I message you privately?

[mbklein]

Sure. My github username is also my username for gmail as well as the IIIF slack team.

[ta1986]

2. The x and y offsets of the requested extract region are larger than the dimensions of the image as reported by https://iiif.trustedkidney.com/iiif/3/test/test1.tiff/info.json.

@mbklein We have the same issue because Universal Viewer generates download links with x ,y larger than dimensions reported by info.json https://collections.nlm.nih.gov/bookviewer?PID=nlm:nlmuid-101392718-img -> Zoom all the way out -> Download -> Current view.

Can we support larger than dimensions x,y or override them so the requests always work?

[mbklein]

Yes, I think I understand what's going on. I'll see what I can do.

[mbklein]

@ta1986 I just realeased serverless-iiif v5.1.5, which should fix the issue you're seeing. It changes the region extraction behavior to conform to Section 4.1 of the IIIF Image API v2.1.1 and v3.0.0:

If the request specifies a region which extends beyond the dimensions of the full image as reported in the image information document, then the service should return an image cropped at the image’s edge, rather than adding empty space.

If the requested region’s height or width is zero, or if the region is entirely outside the bounds of the reported dimensions, then the server should return a 400 (Bad Request) status code.

[ta1986]

@mbklein Thank you so much for the quick fix. New base.js looks good to me. We will upgrade and try it out.

[mbklein]

I realized I left a couple of unnecessary debugging dependencies in package.json. They're harmless but they make the deployment package larger than necessary. I removed them and released v5.1.6.