Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop "full" size #678

Closed
jpstroop opened this issue Dec 22, 2015 · 13 comments
Closed

Drop "full" size #678

jpstroop opened this issue Dec 22, 2015 · 13 comments

Comments

@jpstroop
Copy link
Member

@jpstroop jpstroop commented Dec 22, 2015

See #663 (comment)

@azaroth42
Copy link
Member

@azaroth42 azaroth42 commented Jan 13, 2016

👍 to killing full in 3.0

@mikeapp
Copy link
Member

@mikeapp mikeapp commented Jan 13, 2016

👍 to killing full

@tomcrane
Copy link
Contributor

@tomcrane tomcrane commented Jan 13, 2016

👍

@zimeon
Copy link
Member

@zimeon zimeon commented Jan 13, 2016

👍 to deprecating full as of 2.1 and killing in 3.0

@zimeon
Copy link
Member

@zimeon zimeon commented Oct 20, 2016

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
Copy link
Member Author

@jpstroop jpstroop commented Jan 31, 2018

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

@azaroth42
Copy link
Member

@azaroth42 azaroth42 commented Feb 20, 2018

closed by #1422

@stevewh
Copy link

@stevewh stevewh commented Aug 18, 2019

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
Copy link
Member Author

@jpstroop jpstroop commented Aug 18, 2019

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
Copy link
Member Author

@jpstroop jpstroop commented Aug 18, 2019

(apologies for typos, answering from my phone)

@stevewh
Copy link

@stevewh stevewh commented Aug 18, 2019

@jpstroop
Copy link
Member Author

@jpstroop jpstroop commented Aug 19, 2019

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
Copy link

@stevewh stevewh commented Aug 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants