iipsrv
iipsrv copied to clipboard
Images smaller than the size parameter constraint can't be returned using !w,h (IIIF V3)
There appears to be a regression in how IIP handles images that are smaller than the !w,h
size constraint when switching from IIIF Image API v2 to v3.
Scenario (in my case, at Duke University Libraries)
I need thumbnail images that are no larger than 300px on the long side. For IIIF URLs, this is !300,300
in the size
parameter. My source images are various sizes -- some are as big as 8,000 x 8,000 and others as small as 200 x 200. I cannot permit upscaling due to terms agreed upon with the image copyright holders. And I can't use max
for size -- for the large images these files would be much too big for a thumbnail.
Using V2
IIP version: 1.2
ALLOW_UPSCALING=0
IIIF_VERSION=2
This works as expected. A request using /full/!300,300/0/default.jpg
has the following effect:
- Large image (8,000 x 8,000): returns a 300x300 image.
- Small image (200 x 200): returns the full 200x200 image at its original dimensions; it does not attempt to upscale because the source image is smaller than the maximum size I want back.
Using V3
IIP version: 1.2
ALLOW_UPSCALING=0
IIIF_VERSION=3
This doesn't work for smaller images. It only works for images that are larger than 300px. A request using /full/!300,300/0/default.jpg
has the following effect:
- Large image (8,000 x 8,000): returns a 300x300 image.
-
Small image (200 x 200): returns an
HTTP 400
error with messageIIIF: upscaling should be prefixed with ^
. This is unexpected, since I don't want to upscale it -- I just want the image at its original dimensions if they fall under the maximum dimensions constraint set in the!w,h
size parameter.
According to the IIIF Image API V3 spec for the size parameter:
!w,h
: The extracted region is scaled so that the width and height of the returned image are not greater than w and h, while maintaining the aspect ratio. The returned image MUST be as large as possible but not larger than the extracted region, w or h, or server-imposed limits.
It seems there is some ambiguity in the spec around what "as large as possible" actually means here. I'd be surprised if the way !w,h
should be interpreted changed so significantly between V2 & V3, else I'd expect that to have been listed as a breaking change in the change log.
Looking around at how support for !w,h
has changed in V3 for other image servers, I see that this problem has also been reported as an issue for Cantaloupe:
https://github.com/cantaloupe-project/cantaloupe/issues/600