Drop "full" size

[jpstroop]

See #663 (comment)

[azaroth42]

👍 to killing full in 3.0

[mikeapp]

👍 to killing full

[tomcrane]

👍

[zimeon]

👍 to deprecating full as of 2.1 and killing in 3.0

[zimeon]

Discussion at The Hague, syntax will change from /full/full/0/default to '/full/max/0/default`, servers might well redirect anyway. Might be useful to note the history in the 3.0 spec

[jpstroop]

Consensus on 31 Jan 2018 community call is that this is still OK. This + resolution of #693 solves #1370

[azaroth42]

closed by #1422

[stevewh]

How can one be assured to get the actual size of the original image so that bounding box coordinates (as well as cropping paths) can work with the original image file?

This likely also speaks to the immutability issue of URLs, where a system is built with a dependency on a URL such that the content of the URL returns a constant value (in this case an image with immutable dimensions).

[jpstroop]

If I understand the question: the width and height that reported in the info.json are there so that clients can do the math they need to do to do to make the appropriate request.

Also, there is no notion of an "original" image in the Image API's semantics, e.g. just because a server reports a specific width and height, sizes of tiles, etc, does not mean that the image exists (it could be generated dynamically) or that the server allows retrieval of the entire image--have a look at the explanation of max which was introduced in 2.1.1 and will completely replace full in 3.0.

Regarding URIs and immutability, I believe the section on the canonical syntax should solve any concerns there?

[jpstroop]

(apologies for typos, answering from my phone)

[stevewh]

Thanks Jon for the quick response. Perhaps this thread needs a new issue or is related to a different issue. I have read these parts of the specification and understood the replacement of full with max. I also understand the json.info request. I have an image annotation web app and would like to conform to IIIF. Images in the system can be stored as URLs which includes IIIF urls. The URL is loaded into an <img> element with auto for height and width so that the "full" image is loaded and the coordinates are captured. The system annotates regions of the image using polygonal anchor regions. So for local image files and non-IIIF urls, access to image files assumes that the original size and resolution remains stable. Of course, image files can change on the local system or at the server behind a non-IIIF url without notification, there is a general trust that this will not happen. The point is that the image annotation system tracks the source of the original image and uses the original size/resolution as the known euclidean space for annotation anchors, which supports portability of image annotation anchor regions for an digital facsimile with the same source and resolution (or perhaps a different resolution and a known scale and translation). IIIF Server challenges for the image annotation system as I see them currently: First challenge is to detect a URL as IIIF when the user sets an image url. I believe this can be done by inspecting headers from the URL response or perhaps parsing the URL then sending a json.info request. Is there an easier way? (I noticed some servers using IIIF in the URL and others not). Second challenge is request a stable size image at stable resolution to ensure a guaranteed stable euclidean space. It is this second challenge that I'm referring to in the first email. There seem to be 2 challenges, one being the IIIF server can obfuscate the image name making it impossible to resolve original source. The other challenge is knowing whether the semantic of 'full' size and 'max' resolution are stable or is there a guarantee of stability for a given server? If not, I do I ensure that I retrieve the same image size and resolution? Cheers, Steve

…

On Sun, Aug 18, 2019 at 3:38 PM Jon Stroop ***@***.***> wrote: (apologies for typos, answering from my phone) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#678?email_source=notifications&email_token=AARYOIJNWCPMXGCU6J5SVSTQFFGEJA5CNFSM4BXIXY2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RAH3A#issuecomment-522322924>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARYOIP4563XLUGF4KXPY4DQFFGEJANCNFSM4BXIXY2A> .

[jpstroop]

First challenge is to detect a URL as IIIF when the user sets an image url. I believe this can be done by inspecting headers from the URL response or perhaps parsing the URL then sending a json.info request. Is there an easier way? (I noticed some servers using IIIF in the URL and others not).

Servers MAY add a Link header, but it's not required at any level. See Section 6. There's probably another issue floating around somewhere about this and why we dropped it as a requirement--I think it might be to do with the fact that unless you're loading images w/ Javascript, you'd never have the opportunity to see that header (assuming the image is part of an HTML page) anyway.

Looking for /iiif/ in the URI is definitely not a reliable approach. I guess if you really needed to know, it would require applying a regex to try to check the URI. However--are you planning on then leveraging the Image API in some way (e.g. to request a different image)? If not, I'm not sure why you would care if it's an IIIF image server URI or not.

Second challenge is request a stable size image at stable resolution to ensure a guaranteed stable euclidean space.

We can't control whether a server changes what it makes available as, e.g., it's max size, but I'd say, as a best practice on the web in general (and indeed part of IIIF's best practices), that a new resource should be given a new URI; in the IIIF space that would mean changing the identifier. It's my opinion that you should feel comfortable assuming whatever image your URI is returning will stay the same, and, knowing the IIIF community reasonably well, this isn't just a theoretical opinion on my part.

the IIIF server can obfuscate the image name making it impossible

Is this something your application needs? If so, can you use the whole URI as your identifier/"name"? Between the scheme, server, prefix, and identifier (see Section 2) this should always be globally unique. Up through 2.1.1 we had a buried mention of using the Content-Disposition header for use cases that involved downloading with a server-specified filename, but I don't know that it has ever seen implementation.

[stevewh]

However--are you planning on then leveraging the Image API in some way (e.g. to request a different image)? As an image annotation app it is sometimes necessary to show the annotated region. I wrote a clipping service 10 years ago that I'm still using with local and URI images, for text research applications this can be slow so I can cache them locally. If the URI is detected to be IIIF, I can simply apply the bounding box to the URI. We can't control whether a server changes what it makes available as, e.g., it's max size, I take this to mean that max is mutable, so one should explicitly request the size at it's maximum (likely retrieved from info.json) instead of using max if the requirement is for an immutable URI. In my case the regions are directly dependent on the euclidean dimensions which requires the same image size/resolution be delivered for the stored image URI. Is this something your application needs? If so, can you use the whole URI as your identifier/"name"? Not truly needed, though the ability to apply the region coordinates to other image source is seen as a use case (and likely a requirement for some future version).

…

On Mon, Aug 19, 2019 at 12:20 PM Jon Stroop ***@***.***> wrote: First challenge is to detect a URL as IIIF when the user sets an image url. I believe this can be done by inspecting headers from the URL response or perhaps parsing the URL then sending a json.info request. Is there an easier way? (I noticed some servers using IIIF in the URL and others not). Servers MAY add a Link header, but it's not required at any level. See Section 6 <https://iiif.io/api/image/3.0/#6-compliance-level-and-profile-document>. There's probably another issue floating around somewhere about this and why we dropped it as a requirement--I think it might be to do with the fact that unless you're loading images w/ Javascript, you'd never have the opportunity to see that header (assuming the image is part of an HTML page) anyway. Looking for /iiif/ in the URI is definitely not a reliable approach. I guess if you really needed to know, it would require applying a regex to try to check the URI. However--are you planning on then leveraging the Image API in some way (e.g. to request a different image)? If not, I'm not sure why you would care if it's an IIIF image server URI or not. Second challenge is request a stable size image at stable resolution to ensure a guaranteed stable euclidean space. We can't control whether a server changes what it makes available as, e.g., it's max size, but I'd say, as a best practice on the web in general (and indeed part of IIIF's best practices <https://iiif.io/api/annex/notes/design_patterns/#dont-break-web-caches>), that a new resource should be given a new URI; in the IIIF space that would mean changing the identifier <https://iiif.io/api/image/3.0/#3-identifier>. It's my opinion that you should feel comfortable assuming whatever image your URI is returning will stay the same, and, knowing the IIIF community reasonably well, this isn't just a theoretical opinion on my part. the IIIF server can obfuscate the image name making it impossible Is this something your application needs? If so, can you use the whole URI as your identifier/"name"? Between the scheme, server, prefix, and identifier (see Section 2 <https://iiif.io/api/image/3.0/#2-uri-syntax>) this should always be globally unique. Up through 2.1.1 we had a buried mention <https://iiif.io/api/image/2.1/#a-implementation-notes> of using the Content-Disposition header for use cases that involved downloading with a server-specified filename, but I don't know that it has ever seen implementation. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#678?email_source=notifications&email_token=AARYOIPG6VD4M3MEUYDKC3DQFJXVJA5CNFSM4BXIXY2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4SNGPY#issuecomment-522507071>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARYOIOK6QMOUEIPW4TI22TQFJXVJANCNFSM4BXIXY2A> .