search

IIIF / trc

Technical Review Committee issue review
Apache License 2.0
1 stars 1 forks source link

Make w,h syntax for size in Image API REQUIRED at level 1 #18

Open zimeon opened 5 years ago

zimeon commented 5 years ago

API Issue

IIIF/api#1785 and PR IIIF/api#1799

Preview

https://preview.iiif.io/api/issue-1785/api/image/3.0/compliance/#32-size (required for w,h in level 1 column) vs existing https://iiif.io/api/image/3.0/compliance/#32-size

Summary

In version 2 of the Image API the w, and ,h forms of the size parameter were canonical. In version 3 we have changed to make the form w,h canonical (see IIIF/api#1434 and linked issues). In level 0 implementations servers don't need general support for w,h requests, only for values explicitly specified in the sizes list. In level 2 implementations, support for arbitrary w,h requests has been required in past versions and continues to be required.

The 0.1 alpha draft of Image 3.0 has w,h marked optional in the compliance document which is inconsistent with the canonical syntax.

Proposed Solution

Per discussion in IIIF/api#1785, the editors propose making support for w,h requests mandatory at level 1. This resolves the inconsistency with the canonical syntax. It implies level 1 support for more deforming transformations than just the minimally deforming w, and ,h requests. However, we are not aware of cases where this would make support for level 1 difficult.

mixterj commented 5 years ago

I am a yes vote on this but wanted to note that CONTENTdm's Image Server does not support delivering images outside of the native/default image aspect ratio. We are working on updating the Image Server to do so but we have no set timeline for it. For those that care, the reason for this is that when we developed the Server the assumption was that the client would take care of modifying the aspect ratio in an tag or something similar.

So, support for the proposal with the caveat that it might delay our adoption of Image V3.

beaudet commented 5 years ago

I also voted yes, but I'm wondering if the specification should provide some guidance for image server implementations on how best to maintain the aspect ratio in a way that will provide for consistency across server implementations with respect to computed sizes. For example, if an image is requested to fit inside a bounding box of 317,317, how exactly should the W x H of the resulting image be computed? I'm sure that servers are all producing images within a pixel or two from each other, but should they be all be striving to align their calculations and are there test images, URLs, and expected resulting dimensions that can be built into the next version of the Image API validation tool?

azaroth42 commented 5 years ago

Issue 18 (Make w,h syntax for size in Image API REQUIRED at level 1)

+1: 31 [Siani81 ahankinson aisaac andrewgunther awead azaroth42 beaudet cubap dismorfo emulatingkat gigamorph glenrobson hadro irv jbhoward-dublin jonhartzler joshuago78 jronallo jtweed julsraemy jwd mattmcgrattan mcwhitaker mejackreed mikeapp mixterj regisrob scossu tomcrane tpendragon zimeon] 0: 0 [] -1: 0 []

Result: 31 / 31 = 1.00

Super majority is in favor, issue is approved