You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 message IIIF: 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.
!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: cantaloupe-project/cantaloupe#600
The text was updated successfully, but these errors were encountered:
I'm happy to change the behavior as it does make sense to return a un-upscaled image. I see you've also posted on Slack - let's see what kind of feedback you get before I make any changes.
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 thesize
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 usemax
for size -- for the large images these files would be much too big for a thumbnail.Using V2
This works as expected. A request using
/full/!300,300/0/default.jpg
has the following effect:Using V3
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: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:
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:cantaloupe-project/cantaloupe#600
The text was updated successfully, but these errors were encountered: