dfdan
commented
4 years ago Sorry to dig up an old issue, but this behaviour is still not compliant with the IIIF standard (tell me if this is better handled in a separate issue).
Per the IIIF spec (as linked above), when using !w,h as a size specification:
The image content is scaled for the best fit such that the resulting width and height are less than or equal to the requested width and height. The exact scaling may be determined by the service provider, based on characteristics including image quality and system performance. The dimensions of the returned image content are calculated to maintain the aspect ratio of the extracted region.
(emphasis mine) ie - padding / background-filling the image is not allowed here. The requesting client should be able to handle an image of some size smaller than w,h.
Examples - with the same image/parameters:
-
From Zenodo sandbox, with extra borders : https://sandbox.zenodo.org/api/iiif/v2/8f1d69f7-6778-46f5-b47c-b2684b5d6a10:79435d59-e5e5-4759-b299-f78a863c2a3d:mangamap_small.jpg/full/!200,200/0/default.jpg
-
Served with correct handling of !200,200: https://iiif-dev.freizo.org/image/mangamap_small.jpg/full/!200,200/0/default.jpg
Happy to do a PR fixing this - in order to minimize impact on existing things (CERN Videos/ Zenodo?), I would propose including a config option to keep the current behaviour for implementations that expect it?
ntarocco
lnielsen
When an image resize is requested with
!, the output does not respect the standard: Documentation: http://iiif.io/api/image/2.0/#size!: https://videos.cern.ch/api/iiif/v2/1d0269c8-f4a9-4db9-b262-86cdfd096192:frame-1.jpg/full/400,220/0/default.png!, wrong output: https://videos.cern.ch/api/iiif/v2/1d0269c8-f4a9-4db9-b262-86cdfd096192:frame-1.jpg/full/!400,220/0/default.pngThe algorithm should match the biggest of the desired parameter and resize the image keeping the aspect ratio intact.